A Whole Framework Ported: Imp v0.5 Brings DSPy's Self-Improving Prompts to Elixir's BEAM

The most interesting language-model framework release of the week did not come from San Francisco or Beijing. It came from a GitHub repository named deepfates/imp and landed on Hex, the Elixir package registry, on September 27, 2026. Imp v0.5 bills itself as a complete port of DSPy — the declarative, self-improving prompt framework that reshaped how Python developers think about LLM programming — to the BEAM, the virtual machine that powers Erlang, Elixir, and WhatsApp’s famously unbreakable messaging infrastructure.

If you have never written Elixir, the significance may not be obvious. If you have ever tried to run hundreds of long-lived LLM agents in Python and watched the process table melt, it is.

What DSPy actually solved

DSPy’s core insight was that hand-written prompts are unmanaged configuration. You write a paragraph of instructions, paste it into a template, and hope the model interprets it the way you meant. When the model changes, or the task shifts, the paragraph silently rots. DSPy replaced that practice with declared, typed programs: you specify what each step takes and returns — a signature like "issue -> kind: enum[bug, feature, question], summary" — and the framework compiles the prompt, parses the reply, and validates the output against the declared types.

The second half of the idea is the optimizer. Instead of a human tweaking wording at midnight, you hand the framework labeled examples and a metric, and an optimizer searches for better instructions. The flagship of that family is GEPA, a reflective evolutionary optimizer that runs the program, reads traces of where it failed, and rewrites its own instructions using a stronger “reflection” model. Published benchmarks behind GEPA reported beating GRPO-style reinforcement-learning tuning by roughly 10% on average with 35x fewer rollouts — prompt optimization as a measured engineering discipline rather than folklore.

What Imp brings to the BEAM

Imp ports both halves. A task is a signature piped through Imp.predict, Imp.chain_of_thought, or Imp.react — same signature, different reasoning strategy. The optimizer suite covers the DSPy lineage: LabeledFewShot and BootstrapFewShot for selecting demonstrations, MIPROv2 for joint search over instructions and examples, SIMBA for learning rules from the program’s own better and worse attempts, GEPA for reflective instruction rewriting, and fine-tuning or GRPO when you want to train weights instead of text. Results are inspectable: optimized programs serialize to JSON and can be reviewed as diffs.

The genuinely novel part — the reason this is more than a translation exercise — is how agents run. On the BEAM, an agent is an OTP process. Imp.start_run/3 launches a program as its own supervised process that you can watch, stop, and authorize tool-by-tool. The documentation shows an authorize function denying any tool call whose target URL falls outside https://raw.githubusercontent.com/ — capability-scoped agents as a library primitive, not a platform feature.

The failure semantics are equally BEAM-flavored. Model requests are cut to a deadline you set. A tool call that may already have taken effect is reported as unknown, never silently retried — the same at-most-once discipline database engineers spend careers learning, applied to LLM tool use. Every run emits a structured event stream (:run_started, :tools_sent, :model_request, :tool_call, :tool_result, :run_finished) you can audit after the fact.

Beyond ReAct, Imp ships RLM for inputs larger than a context window, CodeAct and program-of-thought patterns that compute with small sandboxed expressions, MCP client support for importing tools from servers you approve, and ACP serving so any Imp program can appear as an agent inside Zed. Providers are reached through ReqLLM, so anything it supports — OpenAI, Anthropic, local models — works. Optimizers even compose with agents: GEPA can reflect on whole agent runs and rewrite the instructions that steer them, including tool descriptions, via an “Optimize Anything” escape hatch for any text or JSON you can score.

Why the runtime matters for agents

The industry’s agent stacks are converging on Python plus a sandbox plus a retry loop, and the failure modes everyone reports — zombie processes, silent double-execution of side-effecting tools, unobservable runs — are runtime failures, not model failures. The BEAM was engineered for exactly this class of problem: millions of lightweight processes, supervision trees that restart components into a known-good state, per-process garbage collection, and preemptive scheduling that keeps one runaway task from starving the rest.

Imp’s bet is that the agent era will eventually want an actor-model runtime the way the web-server era found Erlang when C++ servers kept falling over. Whether Elixir becomes an agent language depends on ecosystem gravity Python will be hard to dislodge. But a full DSPy port with supervised processes, deadline enforcement, and unknown-effect tool reporting removes the biggest technical excuse not to try.

Caveats worth stating plainly

Imp 0.5 is experimental and this is its first Hex release. The README says so directly: the API may still change, and the optimizers need large-scale benchmarking — the impressive GEPA numbers come from DSPy’s own papers, not from BEAM-specific replication. It requires Elixir 1.19+, a C and C++ compiler for native dependencies (jaxon, erlexec), and network access on first compile for rebar3 plugins. Download counts stood at 93 on the day after release — early-adopter territory, and the 0 dependents figure on Hex confirms nobody’s production stack rides on it yet.

It is also not the first Elixir experiment in this space: gepa_ex shipped a headless GEPA port in April, and DSPex has explored similar ground. Imp’s differentiator is completeness — signatures, modules, the full optimizer family, retrieval, agent loops, MCP, ACP — as one coherent MIT-licensed library rather than a slice.

The takeaway

For fifteen years the BEAM’s pitch was “concurrency you don’t have to think about,” and the industry mostly didn’t. Agents are the first mainstream workload where the runtime’s core competencies — supervision, isolation, message-passing, partial failure — map one-to-one onto the requirements. Imp v0.5 is an early, honest, well-documented stake in that ground: port the best prompt-engineering framework we have, run it on the best concurrency runtime we have, and see what breaks. For Elixir shops it is now trivially installable ({:imp, "~> 0.5"}). For everyone else, it is worth reading purely as a design reference for what agent runtimes should promise.