AgentMesh Gateway ofrece a clientes de IA y agentes de programación un punto de entrada estable. Antes de que una política optimice por latencia, coste, calidad u orden, el sistema determina qué proveedores son realmente viables para esa solicitud.
Una cronología en lenguaje claro que explica por qué nació el proyecto, qué cambió en cada etapa, por qué existen los límites actuales y hacia dónde puede crecer la arquitectura.
AgentMesh comenzó el 22 de agosto de 2026 como una implementación independiente nacida de un problema práctico: los agentes de programación y los clientes de IA necesitan trabajar cada vez con más proveedores locales y remotos, pero esos proveedores difieren en protocolo, herramientas, semántica de reasoning, precio, latencia, fiabilidad y cuotas. Por eso, un router que simplemente “elige el modelo más barato” puede equivocarse antes de que empiece la optimización. El proyecto se diseñó con una regla más estricta: primero determinar qué proveedores pueden conservar la solicitud de forma segura y significativa; después optimizar únicamente entre las opciones viables.
El repositorio se creó como un proyecto original Apache-2.0 con reglas explícitas de procedencia, un modelo de dominio neutral respecto al protocolo, una capa de entrada FastAPI, configuración de proveedores mediante variables de entorno y pruebas que no requieren ninguna API de pago.
Por qué fue lo primero: sin un núcleo neutral, cada proveedor nuevo introduciría supuestos de vendor en el routing y haría menos fiables las comparaciones de investigación.
Chat Completions con forma OpenAI, una superficie parcial de Responses y Messages con forma Anthropic se conectaron a adaptadores genéricos. El routing ordered, latency, cost, quality y balanced, junto con fallback, normalización de reintentos, circuit breaker, autenticación bearer opcional y CI en Python 3.11–3.13 formaron el primer límite funcional del producto.
Por qué había que avanzar: un gateway que solo reenvía texto es útil, pero los agentes de programación también dependen de streaming, llamadas a funciones y semántica propia del protocolo.
Se amplió el ciclo de vida de Responses, se normalizaron los bucles de function calls y los tool deltas en streaming, se añadió un Codex contract harness, se pudieron preservar el reasoning nativo de Responses y las herramientas integradas reconocidas, y la semántica no compatible empezó a devolver errores 4xx explícitos en lugar de desaparecer en silencio.
Por qué era importante: decir que algo “parece compatible” es peligroso si los controles de reasoning o la semántica de herramientas se pierden durante la traducción. v0.2 convirtió la preservación semántica en una restricción explícita de routing.
Se añadieron feasibility basada en capacidades, contabilidad observada de tokens/coste, evidencia de latencia EWMA más p50/p95 acotada, ventanas deterministas de cuota local, un simulador de políticas sin red, perfiles de calidad con procedencia verificable y los baselines adaptive_balanced y constrained_ucb, solo para simulación. La versión se archivó en Zenodo y se documentó mediante GitHub Pages.
Por qué cambió aquí la arquitectura: el proyecto dejó de preguntar solo “¿qué proveedor debe atender esta solicitud?” y pasó a poder estudiar esa decisión de forma reproducible bajo restricciones de coste, latencia, capacidad, fallos y cuota.
Hoy ofrece tres familias de protocolos de cliente, tres familias de adaptadores upstream, routing de producción con feasibility primero, fallback acotado, evidencia de runtime, control local de cuotas, simulación offline, ADR, CI, Docker, metadatos de versión con DOI y un sitio de documentación en tres idiomas.
v0.3.0 no afirma compatibilidad completa con OpenAI Responses, no traduce en silencio semántica que no puede preservar y no activa políticas adaptativas en el routing de producción. Vision, audio y otras dimensiones multimodales también se aplazan hasta que el modelo normalizado pueda representarlas sin pérdida. Son límites de seguridad e integridad investigadora, no afirmaciones de marketing incompletas.
Un investigador puede reproducir las mismas trazas con políticas estáticas y adaptativas, inspeccionar conjuntos de proveedores viables, medir evidencia observada de latencia/coste, modelar presión de cuotas locales, adjuntar procedencia de benchmark a perfiles de calidad, exportar JSON/CSV y ampliar el routing sin pagar llamadas reales durante experimentos deterministas.
La arquitectura actual deja deliberadamente abiertas varias líneas de ingeniería e investigación de alto valor.
Añadir vision, audio, ventana de contexto, garantías de salida estructurada y otras capacidades cuando el modelo neutral pueda representarlas sin pérdida.
Añadir estado PostgreSQL/SQLite, almacenamiento cifrado de secretos, validación de proveedores, historial de auditoría y dashboard operativo.
Añadir exportadores Prometheus/OpenTelemetry, SLO, estadísticas de fiabilidad a largo plazo y paneles más ricos de coste y latencia.
Ampliar fixtures específicos para Claude Code, Cline, OpenCode y más comportamientos de Codex sin debilitar las barreras semánticas.
Publicar procedimientos congelados de benchmarks de coding/agentes, trazas de proveedores y perfiles de calidad con procedencia explícita para evaluar científicamente el routing adaptativo.
Mover políticas adaptativas del simulador al routing real solo después de disponer de evidencia de benchmark, restricciones de seguridad, reglas de rollback y revisión arquitectónica separada.
En lugar de puntuar a todos los proveedores y esperar que gane el mejor, AgentMesh elimina primero las opciones que violarían las restricciones de modelo, protocolo, capacidad, circuito o cuota local.
Un proveedor incompatible no puede ganar simplemente por ser más barato o más rápido.
Se registran uso de tokens, coste observado, latencia EWMA y muestras p50/p95 sin inventar mediciones faltantes.
Las políticas estáticas y adaptativas pueden reproducirse sobre trazas deterministas sin contactar endpoints reales.
La arquitectura separa traducción de protocolo, viabilidad, ranking de políticas, ejecución del proveedor e instrumentación de investigación.
Llega tráfico con forma Chat, Responses o Anthropic.
Mensajes, herramientas y semántica de respuesta pasan a un modelo neutral cuando es posible.
Modelo, circuito, pérdida semántica, capacidades y cuota eliminan opciones inválidas.
La política de producción clasifica únicamente el conjunto viable.
El adaptador gestiona la llamada upstream, errores, reintentos y límites de failover.
La evidencia del runtime sirve para diagnóstico y simulación offline sin cambiar políticas de forma silenciosa.
adaptive_balanced y constrained_ucb existen únicamente en simulación offline.Biografía y enlaces oficiales.
Faramarz Kowsari es autor e investigador residente en Estambul. Centrado en la intersección entre tecnología, educación y crecimiento personal, ha publicado más de 80 títulos digitales en plataformas internacionales. Sus áreas de especialización abarcan Inteligencia Artificial, ingeniería de prompts, estrategias modernas de trading (Smart Money Concepts y trading algorítmico), además de literatura clásica y mindfulness. Junto con su trabajo como autor, desarrolla herramientas educativas basadas en la web y crea contenido de vídeo formativo especializado.
Software versionado, documentación reproducible y metadatos permanentes de citación.
Python 3.11+ con CI en Python 3.11, 3.12 y 3.13.
Desarrollo abierto con reglas explícitas de procedencia y contribución.