Part 2: The Languages

Nov 8, 2025

Posts in this series:

What does Language do for Vivarium?

Language is a fundamental tool of intelligence. The particular form of the language is not nearly as important. But the concept of language, a syntax and grammar that carries meaning, is absolutely fundamental. For animals, this is usually body language, but anyone who has a pet dog or cat knows from experience that a lot of meaning comes through in a particular bark or meow.

In Vivarium, language has an additional function: it is the mechanism for definition and inter-operation. The system is defined using domain-specific languages, and agents use language to interact or to control tools.

Every part of the system, from the world definition to the description of the structure and function of agents to the tools agents can use needs an interface and the most powerful and efficient interface is an instance of a language.

Hence, language capabilities (i.e. form or syntax, semantics, parsers, compilers, etc) are a fundamental element of this system.

What is in a Language?

Among programmers, languages can be a dicey topic.

Some programmers tend to view programming languages as handed down on stone tablets and hence you must be an adherent and religiously defend them as the one true solution.

Others view them as something to go into the desert to create and bestow upon humanity to displace one of the existing religions. Essentially, something of great importance and likely to be Quixotic quest.

And still others are reasonably happy to use whatever language is on the menu today. After all, there's a lot more to life than work.

Our perspective is different from these: Languages are somewhat mundane but still quite powerful tools and we'll make and use them as necessary.

By using "language" as the core interface between the components, the rigidity of something like a REST or gRPC API is avoided. One component could send the other a textual representation, a computation graph, or possibly just a pointer to the data structure that would result from the computation graph. The potential power here is immense.

Consider the way a normal client API (e.g. JSON over HTTPS) request works:

The client computes some data structure.
The data structure is converted to JSON (serialization).
Some component makes an HTTPS request with the JSON payload.
The server receives the payload and deserializes the JSON to internal data structures.
The server computes something.
The server converts the data structure to JSON.
The server sends the JSON back to the client.
The client deserializes the JSON to internal data structures.
The client computes with the data it received from the server.

Wow, that's a lot. Of course, that decoupling between client and server is a powerful aspect of distributed systems and it can enable tremendously valuable capabilities. But, yeah, that's a lot.

Using a language as an interface has a few benefits:

A formal syntax and semantics, including the type system.
The implementation, and the ability to abstract the boundaries between components down to a single system
The opportunity to formally evaluate and model ensembles of agents interacting based on the properties of their interface languages.
The ability to enforce limitations for security on the capabilities an agent has access to.

With languages as the core interface between components, the allowed semantics of the interaction can be formally verified and vary significantly according to the desired security posture.

But Will this Work?

There are numerous reasons why making languages themselves a core component is controversial:

Language tech is extremely fragmented.
Most concerns about language focus on rather irrelevant syntax and sometimes on not-very-interesting semantics (e.g. Rust lifetimes and borrow checker).
Assumptions about "frontend", "middle-end", and "backend" limit the language tool chain unnecessarily.
Compiler writers, almost by definition, do not care about the applications. But in order to understand and utilize telemetry from the application in the compiler, the compiler must care about the application.
AI provides an ideal context to bring together "application" and "application telemetry" with the compiler machinery.

So, will this work? There are some challenges. But these ideas are not new.

Pattern Calculus, created by Barry Jay, who I had the pleasure of seeing speak on this idea years ago at Portland State University, is an idea for a way to enable clients to safely run data queries on a server without the server having to specifically implement that functionality. Properties of the pattern calculus make this secure.

The Unison programming language is a more recent take on distributed programming and is a very interesting system. Unison makes your source code content addressable, and easy to call across system boundaries.

In the next post, I'll talk more about the concept of tools and how agents will use languages to control them in Vivarium.