BeamWeaver

Build AI agents and durable LLM workflows in Elixir.

BeamWeaver brings the practical parts of LangChain, LangGraph, and Deep Agents to the BEAM: agents, tools, graph workflows, streaming, memory, persistence, retrieval, provider adapters, tracing, and production supervision.

It is not a Python wrapper. It is an Elixir library designed for applications that already rely on OTP, supervision trees, Ecto, telemetry, and explicit runtime boundaries.

BeamWeaver is not affiliated with LangChain.

Documentation: weavescope.gitbook.io/beam_weaver

What You Can Build

• Customer support agents with tools, structured output, memory, and traceable model calls.
• Durable multi-step workflows with graph state, checkpoints, retries, interrupts, time travel, and resumable execution.
• Deep research and analysis agents with subagents, planning, virtual filesystems, skills, summarization, and sandboxed tool execution.
• Retrieval pipelines with document loading, splitting, embeddings, vector stores, record managers, and incremental indexing.
• Production LLM services with provider fallback, rate limits, redaction, telemetry, event streams, and WeaveScope tracing.

Core Capabilities

Supported Providers And Models

BeamWeaver ships checked-in model profiles for current provider families and permissive fallback profiles for future compatible IDs. Use explicit provider prefixes when a model name is ambiguous.

Inspect the exact profile set in your checkout:

mix beam_weaver.models.profiles

Install

Add BeamWeaver to your application:

def deps do
  [
    {:beam_weaver, "~> 0.1.0"}
  ]
end

Configure only the providers you use:

config :beam_weaver,
  openai: [api_key: System.fetch_env!("OPENAI_API_KEY")],
  anthropic: [api_key: System.fetch_env!("ANTHROPIC_API_KEY")],
  google: [api_key: System.fetch_env!("GOOGLE_API_KEY")],
  xai: [api_key: System.fetch_env!("XAI_API_KEY")],
  moonshot: [api_key: System.fetch_env!("MOONSHOT_API_KEY")]

Quickstart

Start with the module DSL for application code. The DSL keeps the agent's model, prompt, tools, middleware, memory, and harness-style capabilities in one module, so a reader can see what the agent does without chasing a runtime options map. It also makes the common path much easier: adding planning, prompt caching, conversation compaction, overflow recovery, filesystems, or subagents is a declaration instead of custom orchestration code.

defmodule MyApp.Agents.SupportAgent do
  use BeamWeaver.Agent

  alias BeamWeaver.Agent.Middleware
  alias BeamWeaver.Core.Message

  name "support.reply"
  description "Answer customer support questions with account context."

  model "openai:gpt-5.4-mini", temperature: 0.2, timeout: 30_000
  system_prompt "Answer support questions clearly. Ask for missing details."

  # Agent harness capabilities are regular declarations.
  prompt_caching true
  compact_conversation true
  overflow_recovery true

  middleware do
    use Middleware.TodoList, tool_name: "write_todos"
    use Middleware.ToolCallNormalization
    use Middleware.StructuredOutputRetry, max_retries: 2
    use Middleware.ModelRetry, max_retries: 2, initial_delay: 100, retry_on: :transient
    use Middleware.ToolRetry, max_retries: 1, on_failure: :continue
    use Middleware.ToolCallLimit, run_limit: 8, exit_behavior: :end
    use Middleware.ToolSelection, deny: ["internal_admin_tool"]
    use Middleware.PII, detectors: [:email, :credit_card], strategy: :redact
  end

  def run(question, user) do
    __MODULE__.invoke(%{messages: [Message.user(question)]},
      trace: [
        name: "support.reply",
        user_id: user.id,
        execution_mode: "support_reply",
        fields: %{account_id: user.account_id}
      ]
    )
  end
end

Use BeamWeaver.Agent.build/1 when the agent shape is dynamic or generated from configuration:

defmodule MyApp.DynamicSupportAgent do
  alias BeamWeaver.Agent
  alias BeamWeaver.Core.Message

  def run(question, user) do
    model =
      BeamWeaver.Models.init_chat_model!("openai:gpt-5.4-mini",
        temperature: 0.2,
        timeout: 30_000
      )

    {:ok, agent} =
      Agent.build(
        name: "support.reply",
        model: model,
        system_prompt: "Answer support questions clearly."
      )

    Agent.invoke(agent, %{messages: [Message.user(question)]},
      trace: [
        name: "support.reply",
        user_id: user.id,
        execution_mode: "support_reply",
        fields: %{account_id: user.account_id}
      ]
    )
  end
end

Observability With WeaveScope

Tracing is local by default. Add WeaveScope credentials when you want run trees, model calls, tool calls, token usage, costs, errors, and custom fields in the WeaveScope UI. BeamWeaver automatically uses the queued WeaveScope exporter when both endpoint and api_key are configured.

config :beam_weaver,
  weave_scope: [
    endpoint: "https://app.weavescope.com",
    api_key: System.fetch_env!("WEAVESCOPE_API_KEY")
  ]

Use trace: on agent, graph, runnable, model, or tool calls to attach application identity such as user_id, thread_id, execution_mode, and indexed custom fields.

Documentation

Start here:

• Getting Started
• Thinking In BeamWeaver
• Workflows And Agents
• Deep Agents Quickstart
• Models
• Tracing
• Going To Production

Core guides:

• Agents
• Graph
• Tools
• Messages
• Middleware
• Structured Output
• Event Streaming
• Persistence
• Memory
• Retrieval
• Filesystem
• Sandboxes
• Subagents
• Human-In-The-Loop

Provider guides:

• OpenAI
• Anthropic
• Google
• Moonshot/Kimi
• xAI