Imp ports DSPy to Elixir with self-optimizing LLM programs on the BEAM

A project called Imp, published under the deepfates GitHub account and spotted on the Hacker News front page, is a from-scratch reimplementation of DSPy for Elixir. According to the project's README, Imp is a complete port of the Python framework's ideas to the BEAM virtual machine: language-model calls become declared, typed functions that you can measure and then improve automatically rather than tune by hand.

How programs are declared

Instead of writing prompts and parsing replies, you describe a step with a signature that states its inputs and outputs. Imp builds the prompt from that signature, checks the model's reply against it, and hands back typed fields — or an error if the answer does not conform. In the README's triage example, one output field is constrained to an enum of bug, feature or question, so anything outside those three values fails the call.

The same signature can be swapped between reasoning strategies without rewriting it: Imp.chain_of_thought/2 makes a step reason before answering, and Imp.react/3 attaches tools to turn it into an agent loop.

Optimizers instead of prompt tweaking

The optimization layer is the other half of the port. You provide labeled examples split into training, validation and test sets, plus a metric such as exact match on a field, and Imp scores the program and rewrites it. The GEPA optimizer runs the program, reads where it failed — optionally using a stronger "reflection" model — and writes new instructions. Other optimizers pick worked examples (LabeledFewShot, BootstrapFewShot), search combinations of instructions and examples (MIPROv2), learn rules from the program's own better and worse attempts (SIMBA), or train model weights (fine-tuning, GRPO).

The README stresses that the result stays inspectable: the improved program's instructions and examples are readable text that can be saved as JSON and reviewed as a diff before you ship it.

Agents as OTP processes

On the BEAM, an agent is a process with its own state that runs under a supervisor alongside the rest of an application. Imp.call/2 runs a program in your own process, while Imp.start_run/3 starts it as a supervised run you can watch and stop. Each run emits events — model requests, responses, tool calls and results — and an authorization callback lets you allow or deny individual tool calls, for example restricting a fetch tool to trusted hosts. Tools themselves are ordinary Elixir functions described with a JSON schema.

Failure handling is deliberately conservative: model requests are cut off at a deadline you set, and a tool call that may already have taken effect is reported as unknown rather than silently retried.

Interoperability is broad. Imp can import tools from any MCP server you approve, and can expose any program as an agent to Zed and other ACP clients. Extra module shapes include RLM for inputs far larger than a context window, and CodeAct and program-of-thought, which compute with small sandboxed expressions. The optimizers also work on agents — GEPA can reflect on entire agent runs — and an "Optimize Anything" capability rewrites any text or JSON you can score, such as tool descriptions.

Requirements and maturity

Imp needs Elixir 1.19 or later, a C and C++ compiler for two native dependencies (jaxon and erlexec), and network access for the first build. Models are reached through ReqLLM, so any provider it supports works. Version 0.5 is the library's first release on Hex, and the README is candid about its status: the API may still change, and the optimizers need large-scale benchmarking. The project is MIT licensed, with documentation including a step-by-step getting-started guide, a name-mapping guide for people coming from DSPy, and Livebook tutorials.

Why it matters

DSPy's core bet — treating prompts as programs to be optimized against metrics instead of strings to be hand-tuned — has mostly lived in Python. A full port gives Elixir developers the same signatures, optimizers and agent abstractions while pairing them with a runtime designed for supervised, long-lived, concurrent processes, which is a natural fit for agents in production. The failure semantics matter too: bounded deadlines and no silent retries of possibly-executed tool calls address real operational risks that agent frameworks often gloss over. The caveats are genuine — an experimental 0.5 API and unbenchmarked optimizers — but Imp is an early milestone for building and improving LLM systems natively on the BEAM.