Imp Brings DSPy's Prompt Optimization to Erlang's BEAM VM
A new Hex package brings DSPy's declarative LLM pipeline model to BEAM developers, letting Elixir and Erlang teams tune prompts without running a separate Python service.
Elixir and Erlang developers now have a way to build and optimize language-model pipelines inside their own runtime. A package called Imp, published on Hex, ports the core ideas of DSPy — the Stanford-originated framework for treating prompts as program parameters rather than hand-written strings — to the BEAM virtual machine. The project is early and its repository points to DSPy's own documentation as the reference implementation.
DSPy's premise is that instructions and few-shot examples should be searched for, not typed by hand. A developer declares modules and signatures, then hands the program to an optimizer that tries variations against a metric and keeps what scores best. Imp reproduces that structure on the BEAM, so the same compile-and-evaluate loop that Python teams use becomes available to anyone working in Elixir or Erlang.
The immediate appeal is architectural. Teams already running Phoenix, LiveView, or OTP-based services no longer need to stand up a separate Python process just to tune prompts, which removes a network hop and a second deployment target from the stack. The BEAM's process model also fits the fan-out patterns common in modern AI systems: parallel calls to several providers, retrieval and reranking stages, and multi-agent loops that need to survive a failed request without losing the whole job.
Imp lands in a BEAM ecosystem that has been building out AI tooling for a while. Nx and Bumblebee handle numerical work and local inference, while OTP provides supervision, hot code reloading, and fault tolerance natively. Imp sits at the orchestration layer above those libraries, giving developers a place to compile pipelines and measure them instead of pasting notebook results into application code.
How closely Imp tracks upstream DSPy will shape its adoption. The Python project ships optimizers such as MIPROv2 and GEPA and changes APIs between releases, so any port has to choose between chasing parity and freezing its own interface. Support for hosted providers, local models served through Ollama or vLLM, and the observability tools Elixir teams already run will determine whether Imp stays a curiosity or becomes part of production stacks.
The package is young, with little community feedback yet on performance or API ergonomics. The questions worth asking are concrete: does Imp cover DSPy's full optimizer set, how does it handle streaming and retries inside OTP supervision trees, and will the maintainers publish benchmarks against the Python original? Developers can read the source on Hex and compare behavior with DSPy's documentation before wiring it into anything that matters.