Ask which language to build an AI agent in and you will get the same answer you got in 2024: Python, because the ecosystem. It was a good answer once. In mid-2026 it is mostly a reflex, and it is pointed at the wrong question.
The library-count argument has quietly collapsed. The vendors closed the gap themselves. Anthropic ships official client SDKs in seven languages, with Python and TypeScript as the two flagships, and a Claude Agent SDK in both. OpenAI's Agents SDK exists as openai-agents-python and openai-agents-js, both carrying handoffs, guardrails, sessions, and tracing. LangGraph has a Python original and LangGraph.js, which reached core parity — StateGraph, checkpointing, streaming, human-in-the-loop — and now runs agents at Replit, Uber, LinkedIn, and GitLab. At the SDK layer, parity is real.
So if both languages can call the same models with the same primitives, the decision moves somewhere more honest.
The question is the runtime, not the registry
Here is the part the ecosystem argument keeps missing. An agent is not a script that calls a model. It is a process that runs somewhere, touches things, and ships inside a product. The right language is the one that matches where it runs and what it sits next to — and on that axis Python and TypeScript are not converging at all. They are pulling apart.
Python wins when the agent's work is data-adjacent. If the agent evaluates retrieval quality, fine-tunes or queries a model, churns through pandas frames, or lives in the same repo as the training and RAG-evaluation pipeline, it belongs next to PyTorch and the notebook stack — not across a network boundary from it. This is also where the research frontier lands first. OpenAI's newest Agents SDK capabilities — container-based sandbox execution, the new agent harness — shipped in Python and are following in TypeScript. Pydantic AI has no TypeScript twin at all; it is Python-only by design, built on the validation engine that the data world already runs on.
TypeScript wins when the agent is the application. If the agent streams tokens into a React component, runs as a Vercel or Cloudflare function, and shares its type definitions with the same frontend that renders its output, then putting it in Python means standing up a second service, a second language, and a serialization seam between them. The Vercel AI SDK made this its whole thesis: AI SDK 5 streams over Server-Sent Events natively to the browser and exposes an Agent class that runs in the same Node or edge runtime the product already deploys to. Mastra — 1.0 in January 2026, built by the team behind Gatsby — assumes the agent is part of a TypeScript web app from the first line.
The library count was never the moat. The moat is the network boundary you do or don't have to draw between your agent and the thing it lives inside.
What the single-language tools tell you
The most useful signal in the whole debate is which frameworks refused to port. Pydantic AI stayed Python because its value is the validation layer the scientific stack speaks. Mastra and the Vercel AI SDK stayed TypeScript because their value is sharing one type system and one deployment target with the web. These tools are frequently a better fit than the dual-language SDKs precisely because they assume a runtime instead of hedging across two. A framework that commits to where it runs can be opinionated about everything downstream of that.
The dual-language SDKs hedge for a reason — the vendors don't know which runtime you're in, so they ship both. That's parity for them and a decision deferred to you. When you compare the TypeScript agent frameworks against the new Python SDKs, you'll notice the comparison is rarely about features. It's about which one disappears into your existing stack.
The team is the other half
There is a second axis that no benchmark captures: who maintains this in eight months. An agent is a long-running, debugged-at-3am system. The language your team already reaches for under pressure beats the language with the marginally nicer SDK. A data-science org that lives in Python will debug a Python agent faster than a "better" TypeScript one, and a product team shipping a Next.js app will resent context-switching into Python for the one service that happens to call an LLM.
This is why the framework-feature wars — the kind you see when agent frameworks get compared head to head, or when people weigh the Claude Agent SDK against LangGraph — matter less than they look. By the time you've picked your runtime and your team, the framework shortlist is usually two names, both of which work.
The decision, compressed
Build in Python if the agent's center of gravity is data, models, or evaluation, if it lives in the same repo as your ML work, or if you need research capabilities the day they ship. Build in TypeScript if the agent is a feature of a web product, streams to a browser, deploys to the edge, and would otherwise force you to maintain a second service in a second language.
Stop counting libraries. Both languages have enough. The honest question is where the agent runs, what it touches, and who keeps it alive — and on those three, the answer is rarely a tie.
