Going To Production

BeamWeaver does not provide a hosted deployment platform, langgraph.json, or managed agent server. Production is your Elixir application: OTP supervision, releases, config, database migrations, schedulers, telemetry, and whatever HTTP or job boundary invokes your agents and graphs.

Use this page as a checklist and routing guide. The implementation details live in the linked topic pages so this guide stays small and avoids duplicating memory, sandbox, persistence, guardrail, and streaming docs.

Production Contract

Every production invocation should separate conversation identity from trusted run context:

config = %{"configurable" => %{"thread_id" => "thread-123"}}

context = %{
  user_id: "user-123",
  org_id: "org-456",
  permissions: ["support:read"],
  request_id: "req-789"
}

MyApp.SupportAgent.invoke(input, config: config, context: context)

thread_id scopes checkpointed conversation state. Reuse it for follow-up turns in the same conversation and generate a new one for a separate thread.

context carries per-run facts supplied by your application boundary: user ID, tenant, permissions, feature flags, locale, request IDs, and credential handles. Do not let the model choose ownership values. Derive them from authenticated request/session state and pass them through context: or server_info:.

Identity And Tenancy

BeamWeaver has no built-in user system. Your application should authenticate the request, authorize access, and pass only trusted identity into BeamWeaver.

For memory and filesystem namespaces, derive scope from trusted runtime context: user_id, org_id, agent name, or assistant ID from your own service layer.

See Runtime , Persistence , Memory , and Filesystem .

Deployment Shape

Run BeamWeaver like any other OTP application:

• start agents, queues, stores, and telemetry subscribers under supervision;

• use releases and runtime config for provider keys and endpoint URLs;

• run Ecto migrations for checkpoint, memory, and queue tables;

• use Oban, Quantum, Kubernetes CronJobs, or another scheduler for background consolidation and maintenance work;

• expose your own HTTP, Phoenix Channel, LiveView, or job interface around invoke/3, stream_events/3, and resume APIs.

Do not rely on LangGraph Platform conventions such as langgraph.json, hosted thread APIs, or automatic deployment infrastructure. Integrate those as external services only where your application explicitly chooses to.

Checklist

Invocation Patterns

For request/response APIs, call invoke/3 from a supervised request handler or job process:

case MyApp.SupportAgent.invoke(input, config: config, context: context) do
  {:ok, state} -> {:ok, state}
  {:interrupted, interrupt} -> {:needs_review, interrupt}
  {:error, error} -> {:error, error}
end

For live UIs, call stream_events/3 and forward typed envelopes through your transport:

{:ok, events} =
  MyApp.SupportAgent.stream_events(input,
    config: config,
    context: context,
    live: true
  )

Enum.each(events, fn envelope ->
  MyAppWeb.AgentChannel.push_event(socket, envelope)
end)

Consume a live stream once. If multiple UI components need the same updates, fan out from one process through PubSub, channels, LiveView assigns, or your own projection state.

Secrets

Keep provider API keys, OAuth tokens, database credentials, and customer secrets outside model-visible state. Prefer host-side tools that perform authenticated work without exposing the credential to the model or sandbox.

For sandboxed code execution:

• do not upload secrets as files;

• do not inject broad environment variables into the sandbox;

• restrict network access where possible;

• treat sandbox outputs as untrusted input;

• implement credential proxying or host-side tools when sandbox code must call authenticated APIs.

See Sandboxes , Tools , and Guardrails .

Background Work

Use normal Elixir scheduling and jobs for production maintenance:

• memory consolidation across recent conversations;

• trace export queue flushing and dead-letter handling;

• checkpoint pruning and retention;

• sandbox cleanup by thread or agent scope;

• index refresh and retrieval ingestion;

• eval or conformance jobs against production-like adapters.

These are application jobs, not BeamWeaver-specific hosted cron features. Use Oban or your existing scheduler and invoke BeamWeaver agents, graphs, memory stores, and checkpoint APIs from those jobs.