Burr
Type: full-code · Vendor: Apache Software Foundation (originally DAGWorks) · Language: Python · License: Apache-2.0 · Status: active · Status in practice: emerging
Build stateful decision-making applications (chatbots, agents, simulations) as an explicit state machine of @action-decorated functions with pluggable persisters, a Tracker UI for inspection, OpenTelemetry integration, streaming actions, and fork-and-replay for debugging and evaluation.
Description. Burr is a framework for developing stateful AI applications, donated by DAGWorks to the Apache Software Foundation and incubating there. An Application is a state machine in which @action-decorated functions read from and write to a typed State; transitions between actions are explicit. Built-in features: streaming actions for low time-to-first-token; pluggable Persisters (e.g. SQLLitePersister) for save/load and resume-from-checkpoint; fork and replay (initialize_from with fork_from_app_id) for debugging and evaluation; a tracking UI; and OpenTelemetry integration. Framework-agnostic — works with any LLM library or non-LLM use case.
Agent loop shape. Explicit state machine of actions over typed state. Each step the runtime selects the next @action function based on declared transitions and current state, executes it, applies its state mutations, fires hooks, and records to the configured Persister. Streaming actions return a StreamingResultContainer for incremental consumption. Resumption uses initialize_from(persister, app_id=..., resume_at_next_action=True) to rebuild State from a persisted checkpoint. Fork-and-replay rewinds to any past step via fork_from_app_id, supporting debugging and eval. OpenTelemetry traces and the Tracker UI provide observability.
Primary use cases
- explicit-state-machine chatbots and agents
- RAG and decision pipelines that must persist and resume
- debugging-by-replay via fork-from-app
- OpenTelemetry-instrumented production decision flows
Key concepts
- Action (docs) — Unit of work decorated with @action; reads/writes the state.
- Application — State machine orchestrating actions and transitions.
- State + Transitions — Typed State plus explicit transitions between actions.
- Persister → agent-resumption (docs) — Pluggable state checkpoint store (e.g. SQLLitePersister); custom persisters implement BaseStatePersister.
- Fork & replay → replay-time-travel — initialize_from(fork_from_app_id=...) rewinds and forks state from a previous application.
- Tracker UI + OTel — Open-source telemetry UI for real-time tracing; OpenTelemetry integration for export.
- Streaming actions — stream_result() / astream_result() yield a StreamingResultContainer cached iterator.
Patterns this full-code implements —
- ★★Agent Resumption
Pluggable Persister saves and loads State; initialize_from(persister, resume_at_next_action=True) resumes execution from the last checkpoint.
- ★★Replay / Time-Travel
Forking state from a previous application via fork_from_app_id; documented as 'state snapshots and debugging capabilities'.
- ★★Decision Log
Every action, state mutation, and transition is recorded; Tracker UI provides real-time inspection.
- ★★Lineage Tracking
State snapshots plus fork-from-app give per-run lineage usable for debugging and evaluation.
- ★★Event-Driven Agent
Transitions between actions are condition-driven; hooks fire on lifecycle events; integrates with OpenTelemetry.
- ★★Approval Queue
Hooks and lifecycle adapters enable approval-style gates around node execution; not a dedicated 'approval queue' API.
- ★★Cost Observability
OpenTelemetry integration surfaces cost via custom spans; not a first-class cost panel.
- ★★ReAct
ReAct-style agents are buildable on top of Burr's action/state model; Burr does not ship a ReAct agent class. No ReAct primitive surfaced in README or surveyed concept docs.
- ★★Tool Use
Tools are user-defined @action functions calling external systems; framework is LLM- and tool-agnostic with no dedicated tool abstraction.
- ★★Step Budget
Step budget is user-encoded as state and transition guards; no built-in step-cap primitive in surveyed README or concept docs.
- ★Spec-Driven Loop
Transitions encode the spec for valid runs; not framed in the docs as 'spec-driven'.
Neighbourhood
Click any neighbour to follow the lineage. Scroll to zoom, drag to pan.
Listed as alternative by (2)
References
Provenance
- Last analyzed:
- Last updated:
- Verification status: needs-verification