Por qué terminé construyendo mi agente en TypeScript y no en Python

Hace poco, construyendo un agente para un proyecto, llegué a una bifurcación que muchos devs de JavaScript conocen.

Mi app estaba en TypeScript. El frontend, el backend, todo. Pero para la parte del agente, el mundo entero te empuja hacia Python. Los tutoriales, las librerías, las vacantes, todo asume que la IA se hace en Python. Así que tenía dos caminos: montar una capa de Python solo para el agente, con su microservicio aparte, o quedarme en TypeScript y ver hasta dónde aguantaba LangGraph.js.

Me fui a investigar antes de decidir. Y la sorpresa fue que, para el tipo de agente que estaba construyendo, TypeScript no solo alcanzaba a Python. En varios puntos lo superaba.

Te cuento qué encontré, porque si eres dev de JS quizá estás por tomar la misma decisión.

Un solo código, sin fronteras que cruzar

Lo primero que me frenó de meter Python fue lo obvio: serían dos lenguajes y dos servicios para mantener. Mi estado de agente en Python, mi app en TypeScript, y yo serializando datos entre los dos cada vez que cruzaban la frontera. Quedándome en TS, comparto los mismos tipos desde la interfaz de React hasta el estado del grafo. Un solo código, sin duplicar esquemas, sin bugs en las costuras. Solo eso ya inclinaba la balanza.

Seguridad de tipos frente a un modelo impredecible

Después vino algo que no esperaba: la seguridad de tipos frente a un modelo impredecible. La IA es estocástica, nunca sabes con certeza qué te va a devolver. En TypeScript defino el estado del grafo con tipos estrictos y valido las salidas del modelo con Zod en tiempo de ejecución, antes de que toquen el estado global. Si el modelo devuelve algo con mal formato, lo atrapo justo ahí en vez de que reviente la app tres pasos después. Ese control me dio más tranquilidad que cualquier otra cosa.

Dónde corre importa

Luego está el tema de dónde corre. Mi agente vivía dentro de un producto web que tenía que responder rápido. LangGraph.js corre en Vercel Edge, en Cloudflare Workers, en Lambda, pegado al usuario, con cold starts mínimos. Python no llega a esos entornos. Para un agente embebido en una app web, ese detalle de infraestructura pesa muchísimo.

Concurrencia, el punto ganador

Y el último punto, la concurrencia. Orquestar un agente es básicamente esperar respuestas de red: llamadas al modelo, a la base vectorial, a APIs. El event loop de Node maneja miles de esas conexiones y el streaming de tokens con menos peso en memoria que un servidor síncrono. Justo el tipo de carga que tiene un agente.

Donde Python sigue ganando

Ahora, para ser honesto, no todo es a favor de TypeScript. Y aquí es donde quiero ser claro para que nadie salga a construir mal.

Si mi agente hubiera necesitado entrenar o correr modelos locales, hacer fine tuning, o manipular datos pesado con Pandas y NumPy, me habría ido a Python sin pensarlo. Ese ecosistema es de Python y no tiene rival. Si tu equipo es de data scientists que ya viven en Python, quedarse ahí es lo correcto. Y las funcionalidades nuevas de LangChain suelen salir primero en Python. Nada de eso está en discusión.

Es más, muchas veces la respuesta no es elegir uno. Es normal ver arquitecturas donde el agente pesado corre en Python sobre LangGraph Server, y un frontend en TypeScript lo consume con el SDK oficial y tipos autogenerados. Cada lenguaje en lo que hace mejor.

Mi caso, y hacia dónde va la mayoría

Pero mi caso, un agente con estado, persistencia e intervención humana, viviendo dentro de una app web, es justo donde TypeScript brilla. Y no es un caso raro. Es hacia donde van la mayoría de los agentes que la gente de verdad va a usar.

Al final me quedé en TypeScript. No agregué la capa de Python. Y el agente corre en producción sin problemas.

Te lo cuento por esto: si eres dev de JavaScript y crees que para entrar al mundo de los agentes tienes que aprender Python desde cero, no es cierto. Para este tipo de proyectos, el lenguaje que ya dominas es una opción seria, y en varios casos la mejor.