One stack, all the way down

Your frontend is JavaScript. Your backend is JavaScript. Why is your agent in Python?

It is a question I keep returning to—not because Python is a bad language, but because every extra language creates a seam. And seams are where complexity likes to hide.

The cost of the seam

When a TypeScript product gains a Python agent, the team also gains a second dependency graph, a second deployment target, a second set of conventions, and a boundary that must be crossed on every request.

That boundary looks harmless at first. An HTTP call, a queue, perhaps a small shared schema. As the product grows, it becomes the place where types go soft, errors lose their context, and local development starts to require a small orchestra of processes.

The difficult part is not writing either side. It is keeping both sides in agreement.

The stack you already know

TypeScript teams already have a great deal of infrastructure for building reliable software:

• types that travel from the database to the interface;
• mature tooling for testing, packaging, and observability;
• runtimes that work locally, at the edge, and in long-running services;
• engineers who understand how the system behaves in production.

An agent should be able to inherit those advantages. Its tools can use the same domain types as the application. Its execution can live beside the services it calls. Its failures can appear in the same traces the team already reads.

This is not about translating every Python library. It is about making the common path—models, tools, state, durable execution, and human approval—feel native to the stack where the rest of the product lives.

Ownership matters

The language is only half of it. The other half is ownership.

Agents are moving from experiments into the systems businesses depend on. The runtime that decides what to do next, what data to read, and which action to take is infrastructure. Teams should be able to inspect it, deploy it where their data already lives, and change it without waiting for a vendor's roadmap.

That is why I care about open source and self-hosting. They turn an agent runtime from a service you rent into software you can understand and operate.

What I am building toward

I want a TypeScript team to add an agent without creating a new island inside its architecture: one language, one set of types, one deployment story, and one system the team can own.

One stack does not solve every engineering problem. It does remove an entire category of avoidable ones—and that is a worthwhile place to start.