Four Languages,
One File

how Amplifier goes polyglot without touching the engine

The Frame

Most engines go multi-language by rewriting the engine — this one keeps the engine still

Amplifier's polyglot demo runs a real AI agent whose tools are written in four different languages. The usual way to add a language is to edit the core. This deck is about doing it the other way.

First, the evidence the capability is real.

The usual way: teach the engine each new runtime — a core that must know about everything.
This demo's way: the engine stays fixed; the language-native tools plug in at the edges.

Proof · It's Real

One HTML file runs an agent whose tools are Rust, TypeScript, Python, and Go

The primary-source demo is a single self-contained HTML file: a Rust (WASM) data_transform tool, TypeScript web_research, Python (Pyodide) code_analysis, and Go (WASM) document_builder — all four in the browser.

And it wasn't a marathon to build it.

Rust

WASM · data_transform

TypeScript

web_research

Python

Pyodide · code_analysis

Go

WASM · document_builder

Proof · It's Cheap

One author built the whole four-language agent in ~17 hours across two days

Brian Krabach (Microsoft) authored all 22 commits of amplifier-polyglot-demo, from first to last in a 16.83-hour span (Feb 18–19, 2026). That's only cheap if the engine isn't being rewritten for each language.

Which raises the obvious problem.

22

commits, single author

~17h

first to last commit (16.83h span)

2

calendar days (Feb 18–19, 2026)

4

languages, 1 HTML file

The Tension

Four runtimes should mean four ways to teach the engine — the exact brittle core we want to avoid

Normally, every new runtime forces the engine to grow: another special case, another thing the core must know about. An engine that has to understand Rust and TypeScript and Python and Go is precisely the fragile center this demo is trying not to build.

So what stands between the engine and all four runtimes?

Mechanism · The Contract

Every tool, in any language, speaks one contract: GetSpec + Execute

The language-neutral mechanism is a gRPC ToolService with two calls, GetSpec and Execute, over a generic ToolSpec{name, description, parameters} — not an LSP, just one uniform interface. Any-language tools become callable from any gRPC client.

And the engine on the other side of that contract knows nothing about languages.

// language-neutral tool contract
service ToolService {
  rpc GetSpec(Empty) returns (ToolSpec);
  rpc Execute(Request) returns (Response);
}

message ToolSpec {
  name, description, parameters_json
}

Mechanism · The Kernel

The 556-line Rust WASM kernel carries zero per-language knowledge

The kernel just iterates over a generic list of ToolSpecs and dispatches each call through a JS bridge to whichever runtime owns that tool — a toolRegistry maps web_research→TypeScript, code_analysis→Python, document_builder→Go, Rust in-process.

Because the kernel only sees generic specs, no language ever forces a core edit.

556

LOC in the Rust WASM kernel (lib.rs)

0

per-language branches in the kernel

1

generic ToolSpec it iterates over

4

runtimes reached via the bridge

The Turn

Adding a language stops being a core change and becomes an edge move

Because the engine holds no policy — "Mechanism, Not Policy" — a new language means writing a language-native module against the contract and selecting it in YAML behaviors via source: native://…. Modules implement Provider / Orchestrator / ContextManager; policy lives at the edges.

Here's that pattern proven twice in one evening.

1

Write a module in the language, against the ToolService / trait contract.

2

Wire it in YAML — a behaviors file selects it via source: native://….

3

Leave the engine alone — the thin kernel needs no change.

The Payoff

Same contract, engine untouched — new languages arrive as modules

A Zero-Python Rust-native agent (Provider + Orchestrator + ContextManager + gRPC service) shipped in one day — 13 commits, all Feb 18, 2026. The first Go tool module in the ecosystem landed the same evening as a gRPC ToolService. A TypeScript SDK mirroring the same kernel API followed on Mar 2.

The engine never learned a language — every tool learned to speak the contract.

13

commits · Zero-Python Rust bundle, 1 day

1st

Go tool module in the ecosystem

2

commits · Go document_builder module

TS

SDK mirrors the kernel API (Mar 2, 2026)

Sources

FEATURE STATUS · WORKING PROOF-OF-CONCEPT

Research Methodology & Sources

Data as of: based on repos cloned through Mar 2, 2026. Every metric, date, and name was re-derived from git/gh/grep/wc against the primary repos — no claim retained unless a command reproduced it.

Primary sources: bkrabach/amplifier-polyglot-demo, bkrabach/amplifier-bundle-rust-example, bkrabach/amplifier-module-tool-document-builder-go, bkrabach/amplifier-core-ts, ramparte/amplifier-core.

Commands run:

git log --format='%h %ai %an' --reverse · git rev-list --count HEAD — 22 commits (polyglot-demo), 13 (rust-example), 2 (go-module), 1 (core-ts scaffold)
git log --format='%an <%ae>' | sort | uniq -c — all commits: Brian Krabach <brkrabac@microsoft.com>
wc -l rust/wasm-agent/src/lib.rs — 556 LOC kernel; sed -n '/struct ToolSpec/,/^}/p'
grep 'ToolService|GetSpec|Execute|ToolSpec' server/python-tool/amplifier_module_pb2*.py
grep 'web_research|code_analysis|document_builder' html/bridge.js — toolRegistry runtime mapping
cat behaviors/provider-anthropic-rust.yaml · grep 'native://' — YAML module selection

Primary contributor: Brian Krabach (Microsoft) — sole author across all four repos (22/22, 13/13, 2/2, 1/1 commits).

Gaps & excluded: the "language-agnostic LSP core," "7-days/one-day community" and "M×N" framings were NOT found in any repo (grep returned zero hits) and are excluded. "Mechanism, Not Policy" and "zero core code changes" are design claims from the kernel's own docs, not measured diffs. The demo README's "134 tests" is stale vs. the current tree (168 test functions under html/tests).

Four Languages,One File