BeamWeaver: Agentic Elixir Without the Python Sidecar

Earlier this year, LangChain gave a summary of Coinbase’s enterprise agent platform. Their main assertion was that agents are software, and it is a point we strongly agree with. Coinbase’s original engineering write-up describes a code-first, observable, and auditable approach to agents with a useful rule, prefer the simplest viable runtime and add sidecars only when a use case requires them.

At Caudena, we reached the same conclusion from a different starting point.

BeamWeaver Is the Next Step, Not the Starting Point

Caudena has been a pioneer in applied AI for blockchain intelligence since before agents became an industry-wide focus.

In the summer of 2023, Caudena became the first blockchain intelligence platform to release AI Graph Summaries. The AI-generated investigation reports were the first of its kind and gave analysts an automated second opinion on complex transaction flows. In January 2024, we became the first company to release AI-generated Suspicious Activity Report narrative drafts inside a compliance product.

In 2025, we moved from AI-assisted reporting into agentic investigations. We built workflows in which agents could coordinate investigative steps and began developing MCP-based access to Caudena’s blockchain intelligence, allowing AI systems to query deterministic forensic tools instead of guessing from unstructured context.

In 2026, we continued to work with a particular focus on the agent harness. The tools, middleware, memory, context management, subagents, retries, permissions, and tracing turn a model call into a production agent. After running Python as a sidecar for a while, we decided to reimplement in Elixir the practical capabilities we depended on from LangChain, LangGraph and DeepAgents. That decision became BeamWeaver.

BeamWeaver continues the progression. It is not our first experiment with agents, and it is not a response to a passing trend. It is infrastructure shaped by several years of building AI features for investigators and compliance teams, where outputs must remain explainable, reviewable, and grounded in evidence.

We intend to continue leading practical AI development in our industry. Innovation is not adding a chatbot to an existing product but engineering systems that can investigate, show their work, and operate reliably in production.

Our production systems are built in Elixir. For a while, our agents were not. Like many Elixir teams entering the agent ecosystem, we used a Python sidecar to access the libraries, model clients, and orchestration patterns available there. It helped us move quickly, and Python remains an excellent environment for AI research and prototyping.

Over time, the sidecar stopped feeling simple.

We were operating two runtimes, two dependency graphs, and two release artifacts. Application state crossed a serialization boundary. Startup, shutdown, health checks, timeouts, retries, and configuration had to be coordinated across processes. Logs and traces had to be reassembled after crossing the runtime boundary. When something failed, the operational question was no longer just, “What failed?” It was also, “Which runtime owns the failure?“

The sidecar was not helping us build better agents. It was compensating for the lack of a native Elixir agent library.

So we built one.

Why the BEAM Fits Agentic Systems

Agent workloads are long-running, concurrent, stateful, and failure-prone. They stream events, wait on remote models, call tools, spawn subagents, maintain conversation state, retry transient failures, and sometimes pause for human approval.

Those requirements sound very familiar to anyone who has built production systems on the BEAM.

Elixir and OTP give us lightweight isolated processes, message passing, supervision trees, and explicit state ownership. A failing tool call does not need to take down an entire workflow. A subagent can have its own lifecycle. Long-running work can be supervised, cancelled, and observed. Streaming output maps naturally onto processes and messages instead of being forced through a second service boundary.

GenServers are especially useful here, but not because an LLM call should block inside one. In BeamWeaver, GenServers can own agent lifecycle, state, subscriptions, and cancellation, while supervised tasks perform model and tool work. OTP provides the structure around unpredictable external calls: fault isolation, recovery, and clear ownership.

Most importantly, the agent now lives in the same system as the rest of the application. It can use the existing supervision tree, Ecto boundaries, ETS state, telemetry, configuration, and deployment pipeline. There is no local HTTP hop and no separate Python process to keep alive.

BeamWeaver Is Native Elixir, Not a Wrapper

BeamWeaver brings the practical parts of LangChain to Elixir without embedding or wrapping a Python runtime.

It includes module-defined agents, tools, graph workflows, subagents, memory, structured output, streaming, human-in-the-loop interrupts, checkpoints, retrieval, persistence, and tracing. Stable application agents can be expressed with a compact semantic DSL, while dynamic systems can use runtime builders and lower-level graph APIs.

Here is a small example:

defmodule MyApp.Agents.CaseAnalyst do
  use BeamWeaver.Agent

  alias BeamWeaver.Agent.Middleware

  name "case_analyst"
  model "anthropic:claude-sonnet-4-6", timeout: 120_000

  prompt_caching true
  compact_conversation true

  tools do
    tool MyApp.Tools.SearchEvidence
    tool MyApp.Tools.SaveFinding
  end

  subagents do
    subagent MyApp.Agents.SourceReviewer, capture_output: :source_review
  end

  middleware do
    use Middleware.ModelRetry, max_retries: 2, retry_on: :transient
    use Middleware.PII, detectors: [:email], strategy: :redact
  end

  system_prompt "Investigate carefully and ground every conclusion in evidence."
end

The value is not simply that the code is short. The agent’s model, tools, subagents, runtime behavior, and safety boundaries are visible in one normal Elixir module. They can be reviewed, tested, and versioned with the rest of the application.

When a workflow needs deterministic control, BeamWeaver also provides graph primitives for explicit branches, fan-out, joins, retries, durable execution, and human review. Business rules do not need to disappear into a prompt just because an LLM participates in the workflow.

One Runtime, All Major Model Providers

Removing the Python sidecar did not mean accepting a narrow model ecosystem.

BeamWeaver supports the major providers we use and expect teams to need. OpenAI, Anthropic, Gemini, Kimi, Grok, and Z.ai are all available. Its provider adapters cover model profiles, tool calling, structured output, streaming, prompt caching, token usage, and cost metadata, while permissive profiles allow compatible future model IDs to be adopted without waiting for a library release.

This provider coverage creates an important benefit beyond portability: visibility.

Every provider exposes different request shapes, streaming events, usage fields, cache metadata, and error responses. BeamWeaver normalizes those differences into a consistent Elixir runtime while preserving provider-specific details that matter. That gives teams a common way to inspect an agent run even when a workflow switches models or uses several providers at once.

We will cover this in-depth in our next post, where we will show how BeamWeaver and WeaveScope trace complete run trees across agents, graphs, model calls, tools, subagents, and retries, including token usage, costs, errors, and provider metadata.

Ready for Industry Use

We released BeamWeaver as open source on June 12. We have shipped fourteen releases since then and expanded provider support, hardened streaming structured output, and improved caching and tracing.

After more than a month in the open, we are comfortable calling BeamWeaver stable enough for industry use.

That does not mean the work is finished. Agent platforms are evolving quickly, and provider APIs change constantly. It means the core runtime, abstractions, and operational boundaries are now solid enough for teams to build real systems on them—and for us to stand behind that use.

BeamWeaver is released under the Apache License 2.0. It can be used, modified, and extended in commercial and open-source applications without a proprietary hosted runtime.

If your Elixir application currently talks to its agents through a Python sidecar, BeamWeaver offers another path: keep the agent, its state, and its failure model on the BEAM.

Explore BeamWeaver on GitHub, install it from Hex, or start with the documentation.

BeamWeaver is not affiliated with LangChain.