Last time, in Source Code as the Seam Between Systems, I closed by saying I had built a programming language for the seam between systems, and that I would come back to it.
Here we are.
The language is called Neander (named after the Neanderthal), and its specification is available now.
A quick recap of where the last post left us. When one system needs another to do something, the seam between them used to be a wire carrying structured data, with a human in the middle writing the integration code. Take the human out, let the calling system be an agent that decides at runtime what it needs, and the seam stops being a wire. It becomes a language. The called system exposes an execution environment, and the caller drives it by sending small programs.
Neander is that language.
The inversion
The model everyone started with is the tool catalog: load every function the host exposes into the agent's context, then let the agent pick. It does not scale. Hundreds of tool definitions clutter the context, every intermediate result piles up on top, and costs and latency climb with them.
Neander turns that around. The agent's context holds one compact thing — the Neander Reference itself — rather than a catalog of everything the host can do. To get something done, the agent writes a short program. The program asks the runtime what APIs are available, calls what it needs, composes the results, and hands back a single answer. Discovery happens at runtime, inside the program, instead of up front in the context window.
That gives the language two verbs that carry most of the weight. discover asks the runtime what namespaces, functions, and documents exist; call invokes one of those functions. Everything else — branching and bounded loops, the structural type system, explicit error handling — exists to glue those two together.
First the agent looks around:
neander 1 {
types {}
main -> [Function] {
let ns: Namespace =? discover namespace "bookings"
return discover functions ns []
}
}
It reads the returned descriptions, then writes a second program that calls what it found:
neander 1 {
types {}
main -> decimal(2, half_away) {
let booking: bookings.Booking =? call bookings.get(id: 8821)
return booking.fare
}
}
That is essentially the whole shape of it. One call, maybe a loop over the result, some conditional logic, another call. The agent writes it for a single task, sends it to the runtime, and throws it away.
The interesting bit is where the code runs. The Neander runtime lives inside the host: the embedding application registers its own APIs with it, so execution happens server-side, right next to these APIs. As described above, the agent stays on the outside, untrusted, and uses the language to talk to the embedding application.
This setup, obviously, raises a few eyebrows.
What Neander deliberately cannot do
The reassurance is structural, not a promise to behave. The things that make running a stranger's code dangerous don't exist in Neander — there's nothing to wall off because there's nothing there.
- It cannot run forever. Deliberately not Turing-complete: no recursion, every loop statically bounded. Termination is proven before the program runs — no halting question to lose sleep over.
- It cannot reach out. No file I/O, no sockets, no system access. The only thing a program can touch is an API the host chose to register. There's no sandbox because there's nothing to put in one — the language is the sandbox.
- It cannot run up a bill. Every execution runs under hard ceilings on computation, memory, and time (the budget system). Exceed one and that program is stopped — not the host it runs in.
- It cannot misuse the host's APIs. A program that fails validation never runs; one that passes calls only functions that exist, with correctly-typed arguments, and can never treat a value that might be missing as if it were there.
The name fits the philosophy. Like the spare, limited languages of computing's early days, it can do very little — and the less a language can do, the less can go wrong.
The audience
Neander is written for an unusual audience. Only agents author it; humans host it. Hence no getting-started guide, no tutorials — nothing for a manual coder.
Besides the normative specification, the example-driven Neander Reference is aimed squarely at the agents that will write the programs — and the runtime hands it to them in-band.
The website at newadventuresinit.github.io/neander is for the humans evaluating Neander and deciding whether to embed it into their systems. But before they can put it to work, one thing has yet to be published: a reference runtime implementation.
It already exists — more on that next time.
In the meantime, the Neander specification is live, the license is permissive, and the floor is open. Have a look around, and let me know what you think.
