Pith. sign in

REVIEW 4 major objections 4 minor 31 references

A Behavior Tree-inspired programming language for autonomous agents

T0 review · 4 major / 4 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper argues that behavior trees should be rebuilt as a small functional language whose four primitives—reactive selection, monitoring, bind, and fallback—make complex agent behavior precise, modular, and executable.

desk verdict Useful conceptual analysis of Behavior Tree reactiveness, but the paper overclaims a full implementation—the reactive primitives are undefined and the main example does not typecheck. read the letter →

arxiv 2412.08654 v1 pith:ORJOSLU3 submitted 2024-11-26 cs.PL cs.AIcs.ROcs.SE

Oliver Biggar , Iman Shames This is my paper · ORCID
classification cs.PLcs.AIcs.ROcs.SE
keywords behaviortreesautonomousagentsreactiveprogrammingfunctionalHaskellroboticsmodularitymonitoring
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Behavior Trees (BTs) are popular for designing autonomous agent behavior, but the tick-based model becomes ambiguous when actions take real time, pass data, or interrupt one another. The paper claims the solution is to grow BTs into a full programming language built on a few functional primitives: rSelect for reactive selection, monitor for one-sided interruption, bind for sequencing with data flow, and fallback for exception handling. The authors identify a 'progress problem' in reactive Sequence and Fallback nodes and a 'chattering' problem in symmetric reactive selection, arguing that these show the standard BT control nodes are not modular enough for complex behavior. They provide a specification and a Haskell implementation, then reduce a large textbook BT to a short, unambiguous, executable program. The result, if correct, is that behavior design becomes precise, modular, and composable in the same way functional programs are.

What carries the argument

The load-bearing mechanism is the Behavior type, defined as a synonym for Haskell's IO type, so a behavior is an asynchronous action that eventually returns a value of a declared type or raises an exception. Four operations carry the argument: rSelect, a reactive if-then-else that repeatedly evaluates a condition and switches between two behaviors whenever the condition changes; monitor, which runs a task while checking a condition and, when the condition turns true, interrupts the task and runs a recovery action to completion; the bind operator (>>=), which sequences behaviors and passes the first result into the second; and fallback, which catches a specific BehaviorFailed exception and runs a second behavior. Together these operations replace the tick mechanism, the Success/Failure/Running flags, and the blackboard, and they give every aggregate behavior a definite meaning.

What would settle it

Build a task in the proposed library as a long-running IO action that never checks for cancellation, place it under monitor with a condition that becomes true mid-run, and observe whether recovery starts only after the task returns; if it does, Definition 3.2 is not realized by the specified typing.

Watch

Extended reading notes

Core claim

The paper's central claim is that the useful content of Behavior Trees can be captured by a small set of functional programming primitives, and that these primitives, not the tree nodes, should be the language of autonomous-agent behavior. Concretely, the paper argues that reactive selection—a reactive if-then-else that switches between two behaviors whenever a condition changes—handles the cases where one behavior should interrupt another symmetrically, while monitor handles the asymmetric case where a low-priority task runs until a high-priority condition triggers a recovery action that must run to completion. Data flow between behaviors is handled by monadic bind, which is exactly the sequencing-with-memory of BTs with values attached, and failure is handled by fallback, an exception-catching construct rather than a reactive node. On this basis the paper gives a full specification and a Haskell implementation, and it translates a well-known large BT into a short executable program, claiming the translation is precise rather than interpretive.

Load-bearing premise

The load-bearing premise is that a robotic action can be modeled as a Haskell IO action whose running computation can be safely cancelled mid-flight when monitor or rSelect switches behaviors, yet the paper gives no implementation of monitor to show that this preemption is achievable.

Editorial extensions

If this is right

  • A BT that is not in reactive selection form is inherently ambiguous; using rSelect, monitor, bind, and fallback removes that ambiguity by giving each behavior one explicit meaning.
  • The Success/Failure/Running flags can be replaced by return types and exceptions, so a Condition becomes simply a Behavior Bool and a failed action is distinguishable from a false condition.
  • The translation of the Figure 2 behavior into the proposed language is claimed to be precise executable code, meaning the tree's intended interpretation is fixed rather than left to the reader.
  • Because the language is embedded in Haskell, ordinary programming constructs like loops, lists, and named functions extend the behavior language without building new tree nodes.
  • Existing BT design techniques such as backchaining and explicit success conditions are captured naturally by rSelect and monitor.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper leaves implicit that the progress problem is a general critique of tick-polled reactive architectures, not just BTs; if the argument holds, any such framework should prefer event-driven interruption to periodic polling.
  • A testable extension would be to implement monitor with lightweight threads and asynchronous exceptions and measure whether chattering disappears relative to an auxiliary-variable BT; the paper specifies the semantics but does not validate the implementation.
  • The design's portability is open: the Behavior type is tied to Haskell's IO, so moving the primitives to a robotics stack would require deciding how action failure and preemption map onto the host language's concurrency model.
  • One direction the authors do not develop is compositional reasoning: because the language is functional, rSelect, monitor, and bind may admit equational laws that could support verification of safety properties such as 'the agent always recharges before the battery dies.'
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 4 minor

Summary. The paper proposes a behavior programming language for autonomous agents, embedded in Haskell, built around a small set of functional primitives: monadic bind for sequencing with data flow, fallback as exception catching, rSelect for reactive selection, and monitor for one-sided safety interruption. The authors argue that these primitives resolve the 'progress problem' and the 'chattering problem' they identify in Behavior Tree (BT) formalisms, and they present the design as a full specification with a Haskell implementation. The paper demonstrates the language by translating a well-known BT from the literature into a concise Haskell program.

Significance. The conceptual analysis is valuable: the paper clearly identifies the progress problem, the ambiguity of non-reactive selection BTs, and the chattering issue in reactive selection, and it proposes a coherent minimal set of operations that address these concerns while preserving modularity. The use of Haskell's monadic bind for data-aware sequencing and the treatment of fallback as exception handling are well motivated and illustrated with concrete examples. However, the central claims of a 'full specification' and a 'precise, executable' translation are not supported by the manuscript as written, because the reactive operations are not actually specified or implemented, and the main example contains a code fragment that does not typecheck. The paper's strengths are its conceptual contributions and the clarity of its motivating examples; its weaknesses are in the completeness and verifiability of the claimed implementation.

major comments (4)
  1. [Section 5; Definition 3.2] The specification is incomplete: the reactive operations rSelect and monitor are described only by type signatures and informal prose, with no defining equations or implementation code. This contradicts the abstract's claim of a 'full specification' and 'an implementation in Haskell.' In particular, monitor's Definition 3.2 requires preemptively halting an arbitrary running Behavior when a test becomes true; since Behavior is a type synonym for IO, this requires cancellation of an arbitrary IO action. Haskell's async exceptions do not guarantee prompt or clean interruption of all IO actions (e.g., blocking FFI calls, masked sections, or cleanup handlers), so it is not evident that monitor is implementable as specified. The manuscript must either provide a concrete implementation or a more precise operational semantics that accounts for cancellation behavior.
  2. [Section 6, first code block] The first version of the example contains the expression 'if (isOpen frontDoor) then ... else ...', where 'isOpen frontDoor' has type Behavior Bool, not Bool. Haskell's built-in 'if' requires a Bool condition, so this code does not typecheck. This directly contradicts the claim that the translation is 'precise, executable code.' The later unless-based version is valid, but the paper presents the earlier fragment as using 'only the most basic operations,' so the error is in the primary demonstration of the language.
  3. [Section 3.1, Definition 3.1] The failure semantics of rSelect are underspecified. Definition 3.1 states that rSelect fails when either left or right fails, but it does not state what happens when the condition test fails (i.e., raises an exception). Since test is a Behavior Bool, it can fail just like any other behavior, and the behavior of rSelect in that case is left ambiguous. A full specification must define the outcome when test raises an exception, as this affects the composability and safety properties of the language.
  4. [Section 7, Conclusions] The conclusion lists 'constructing a full implementation capable of performing non-trivial tasks on real hardware' as future work, which is in tension with the abstract and Section 5's claim that the paper provides 'an implementation in Haskell.' The manuscript should clarify what the current implementation actually covers and what the future work entails; otherwise the scope of the claimed implementation is misleading.
minor comments (4)
  1. [Section 3.1] The argument that a BT has unambiguous reactive semantics only when it is in reactive selection form is stated informally and not formally justified. A formalization of tick semantics and a proof of the claimed ambiguity would strengthen the paper's central thesis.
  2. [Section 5, Parallelism] The operations parallel and both are given type signatures but no implementation or precise semantics. The manuscript should at least state whether they are implemented via async/race or a custom scheduler, since the claimed 'full specification' should cover these operations.
  3. [Section 6] The list-based fallback function (fallback (x:xs) bhvr = bhvr x ? fallback xs bhvr) lacks a type signature. Adding one would improve readability and clarify the intended use, especially since the name 'fallback' is overloaded with the binary version.
  4. [Section 4.1] The discussion of Booleans and branching is clear, but the example 'monitor dangerNearby hide doTask' is not fully type-correct as written because monitor requires recovery :: Behavior (), while hide would plausibly return some value; a concrete instantiation would help.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: no equation or fitted value reduces to its own input, and the design rests on external BT examples rather than on the authors' prior results.

full rationale

This is a design paper, not a derivation, and the main circularity patterns do not apply. The primitives rSelect, monitor, >>=, and fallback/catch are introduced by explicit intended semantics (Definitions 3.1 and 3.2 and Section 5) and are motivated by standard BT examples drawn from the external textbook of Colledanchise and Ögren, not fitted to any dataset or forced by the authors' own theorems. Section 6 is an interpretation of the published Figure 2 BT into the proposed language, not a prediction that is equivalent by construction to an input parameter. The self-citations [2]–[5] support background claims about BT formal methods, modularity, and the importance of stateful behavior; none is load-bearing for the central design claim. Two non-circular completeness issues should be noted: Section 5 gives type signatures but no defining equations for rSelect, monitor, parallel, and both, and the first Section 6 snippet uses `if (isOpen frontDoor)` where `isOpen :: Door -> Behavior Bool` while Haskell's `if` needs a plain `Bool`, so the claim that the code is 'precise, executable code' is not verifiable as printed. These omissions affect implementability, not circularity, so the score remains 0.

Assumptions & free parameters 0 free parameters · 5 assumptions · 3 invented entities

The central claim rests on design assumptions about robotics and Haskell semantics rather than fitted parameters. Free parameters: none. The axioms are domain assumptions about behavior modeling and implementation feasibility.

assumptions (5)
  • domain assumption An Action (Behavior) may take time and cannot necessarily be decomposed into atomic tick-sized chunks.
    Central to the 'progress problem' argument in Section 3.1; assumes real robotic actions are not atomic at tick granularity.
  • ad hoc to paper A BT only has unambiguous reactive semantics when it is in reactive selection form.
    The paper uses this claim to justify rSelect as a fundamental primitive; it is argued from examples but not proven (Sections 3.1 and 3.2).
  • ad hoc to paper Failure of a behavior can be represented as an exception, and a Condition that fails should raise an exception rather than return False.
    Underpins the removal of Success/Failure/Running flags and the design of fallback as catch (Section 4.1).
  • domain assumption Global variables (Blackboards) are bad for modularity, so data must pass only through function composition.
    Design philosophy taken from structured programming; used to select bind/>>= as the sequencing operator (Section 4).
  • domain assumption Haskell's IO monad and exception handling faithfully model asynchronous robotic actions and failures.
    The implementation rests on this equivalence (Behavior = IO), stated in Section 5 without proof.
invented entities (3)
  • rSelect (reactive selection)
    purpose: Primitive for two-sided reactive if-then-else, switching between behaviors when a condition changes.
    Defined in Definition 3.1 and used throughout, but no shipped implementation or formal semantics; its correctness as a primitive is argued only by examples.
  • monitor (one-sided interruption)
    purpose: Primitive for prioritized interruption: run a task while monitoring a condition, and run a recovery to completion when the condition holds.
    Although the paper notes monitor generalizes teleo-reactive programs [23], the specific implementation in Haskell is not provided, and no falsifiable test is given.
  • parallel and both operations
    purpose: Primitives for racing and joining behaviors.
    Only type signatures are given in Section 5; no implementation or tests provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Behavior Tree-inspired programming language for autonomous agents." pith.science (2026). https://pith.science/paper/ORJOSLU3

@misc{pith2026241208654,
  author       = {Pith},
  title        = {Pith review of: A Behavior Tree-inspired programming language for autonomous agents},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ORJOSLU3}},
  note         = {Machine review of arXiv:2412.08654}
}
read the original abstract

We propose a design for a functional programming language for autonomous agents, built off the ideas and motivations of Behavior Trees (BTs). BTs are a popular model for designing agents behavior in robotics and AI. However, as their growth has increased dramatically, the simple model of BTs has come to be limiting. There is a growing push to increase the functionality of BTs, with the end goal of BTs evolving into a programming language in their own right, centred around the defining BT properties of modularity and reactiveness. In this paper, we examine how the BT model must be extended in order to grow into such a language. We identify some fundamental problems which must be solved: implementing `reactive' selection, 'monitoring' safety-critical conditions, and passing data between actions. We provide a variety of small examples which demonstrate that these problems are complex, and that current BT approaches do not handle them in a manner consistent with modularity. We instead provide a simple set of modular programming primitives for handling these use cases, and show how they can be combined to build complex programs. We present a full specification for our BT-inspired language, and give an implementation in the functional programming language Haskell. Finally, we demonstrate our language by translating a large and complex BT into a simple, unambiguous program.

Figures

Figures reproduced from arXiv: 2412.08654 by the authors.

Figure 1
Figure 1. An example of a BT programmed in our language. This desired speci [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. A Behavior Tree for a complex robotic task, from [10]. [PITH_FULL_IMAGE:figures/full_fig_p010_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

31 extracted references · 31 canonical work pages

  1. [1]

    Behavior trees: Breaking the cycle of mis- use

    Bobby Anguelov. Behavior trees: Breaking the cycle of mis- use. https://takinginitiative.wordpress.com/2020/01/07/ behavior-trees-breaking-the-cycle-of-misuse/ . Accessed: 2020-10- 27

    work page 2020

  2. [2]

    A framework for formal verification of behavior trees with linear temporal logic.IEEE Robotics and Automation Letters, 5(2):2341–2348, 2020

    Oliver Biggar and Mohammad Zamani. A framework for formal verification of behavior trees with linear temporal logic.IEEE Robotics and Automation Letters, 5(2):2341–2348, 2020

    work page 2020

  3. [3]

    A principled analysis of Behavior Trees and their generalisations

    Oliver Biggar, Mohammad Zamani, and Iman Shames. A principled analysis of behavior trees and their generalisations. arXiv preprint arXiv:2008.11906, 2020

    work page Pith review arXiv 2008

  4. [4]

    An expressiveness hierarchy of behavior trees and related architectures

    Oliver Biggar, Mohammad Zamani, and Iman Shames. An expressiveness hierarchy of behavior trees and related architectures. IEEE Robotics and Automation Letters, 6(3):5397–5404, 2021

    work page 2021

  5. [5]

    On modularity in reactive control architectures, with an application to formal verification

    Oliver Biggar, Mohammad Zamani, and Iman Shames. On modularity in reactive control architectures, with an application to formal verification. ACM Transactions on Cyber-Physical Systems (TCPS) , 6(2):1–36, 2022

    work page 2022

  6. [6]

    Improving the parallel exe- cution of behavior trees

    Michele Colledanchise and Lorenzo Natale. Improving the parallel exe- cution of behavior trees. In Proceedings of International Conference on Intelligent Robots and Systems , pages 7103–7110. IEEE/RSJ, 2018

    work page 2018

  7. [7]

    Handling concurrency in be- havior trees

    Michele Colledanchise and Lorenzo Natale. Handling concurrency in be- havior trees. IEEE Transactions on Robotics, 38(4):2557–2576, 2021. 26

    work page 2021

  8. [8]

    On the implementation of be- havior trees in robotics

    Michele Colledanchise and Lorenzo Natale. On the implementation of be- havior trees in robotics. IEEE Robotics and Automation Letters, 6(3):5929– 5936, 2021

    work page 2021

Show all 31 references
  1. [9]

    How behavior trees generalize the teleo-reactive paradigm and and-or-trees

    Michele Colledanchise and Petter ¨Ogren. How behavior trees generalize the teleo-reactive paradigm and and-or-trees. In 2016 IEEE/RSJ Interna- tional Conference on Intelligent Robots and Systems (IROS) , pages 424–

    2016

  2. [10]

    Behavior Trees in Robotics and Al: An Introduction

    Michele Colledanchise and Petter ¨Ogren. Behavior Trees in Robotics and Al: An Introduction . CRC Press, 2018

    2018

  3. [11]

    Notes on structured programming, 1970

    Edsger Wybe Dijkstra et al. Notes on structured programming, 1970

    1970

  4. [12]

    Behaviortree.cpp

    Davide Faconti and Michele Colledanchise. Behaviortree.cpp. https:// www.behaviortree.dev/. Accessed: 2024-11-12

    2024

  5. [13]

    Behavior trees in action: a study of robotics applica- tions

    Razan Ghzouli, Thorsten Berger, Einar Broch Johnsen, Swaib Dragule, and Andrzej Wasowski. Behavior trees in action: a study of robotics applica- tions. In Proceedings of the 13th ACM SIGPLAN International Conference on Software Language Engineering , pages 196–209, 2020

    2020

  6. [14]

    Evaluating behavior trees

    Simona Gugliermo, David C´ aceres Dom ´ ınguez, Marco Iannotta, Todor Stoyanov, and Erik Schaffernicht. Evaluating behavior trees. Robotics and Autonomous Systems, 178:104714, 2024

    2024

  7. [15]

    Introduction to automata theory, languages, and computation

    John E Hopcroft, Rajeev Motwani, and Jeffrey D Ullman. Introduction to automata theory, languages, and computation. Acm Sigact News, 32(1):60– 65, 2001

    2001

  8. [16]

    A survey of behavior trees in robotics and ai

    Matteo Iovino, Edvards Scukins, Jonathan Styrud, Petter ¨Ogren, and Christian Smith. A survey of behavior trees in robotics and ai. Robotics and Autonomous Systems , 154:104096, 2022

    2022

  9. [17]

    Handling complexity in the halo 2 ai, 2005

    D Isla. Handling complexity in the halo 2 ai, 2005. URL: http://www. gamasutra. com/gdc2005/features/20050311/isla 01. shtml [21.1. 2010] , 2015

    2005

  10. [18]

    Improving the performance of learned controllers in behavior trees using value function estimates at switching boundaries

    Mart Kartaˇ sev and Petter ¨Ogren. Improving the performance of learned controllers in behavior trees using value function estimates at switching boundaries. IEEE Robotics and Automation Letters , 2024

    2024

  11. [19]

    Embedded software

    Edward A Lee. Embedded software. In Advances in computers, volume 56, pages 55–95. Elsevier, 2002

    2002

  12. [20]

    Robot operating system 2: Design, architecture, and uses in the wild

    Steven Macenski, Tully Foote, Brian Gerkey, Chris Lalancette, and William Woodall. Robot operating system 2: Design, architecture, and uses in the wild. Science robotics, 7(66):eabm6074, 2022

    2022

  13. [21]

    Haskell 2010 language report

    Simon Marlow et al. Haskell 2010 language report. 2010. 27

    2010

  14. [22]

    Towards a unified behavior trees framework for robot control

    Alejandro Marzinotto, Michele Colledanchise, Christian Smith, and Pet- ter ¨Ogren. Towards a unified behavior trees framework for robot control. In Proceedings of International Conference on Robotics and Automation , pages 5420–5427. IEEE, 2014

    2014

  15. [23]

    Teleo-reactive programs for agent control

    Nils Nilsson. Teleo-reactive programs for agent control. Journal of artificial intelligence research, 1:139–158, 1993

    1993

  16. [24]

    Increasing modularity of uav control systems using computer game behavior trees

    Petter Ogren. Increasing modularity of uav control systems using computer game behavior trees. In Aiaa guidance, navigation, and control conference, page 4458, 2012

    2012

  17. [25]

    Convergence analysis of hybrid control systems in the form of backward chained behavior trees

    Petter ¨Ogren. Convergence analysis of hybrid control systems in the form of backward chained behavior trees. IEEE Robotics and Automation Letters , 5(4):6073–6080, 2020

    2020

  18. [26]

    Behavior trees in robot control systems

    Petter ¨Ogren and Christopher I Sprague. Behavior trees in robot control systems. Annual Review of Control, Robotics, and Autonomous Systems , 5(1):81–107, 2022

    2022

  19. [27]

    Behavior trees with dataflow: Coordinating re- active tasks in lingua franca

    Alexander Schulz-Rosengarten, Akash Ahmad, Malte Clement, Reinhard von Hanxleden, Benjamin Asch, Marten Lohstroh, Edward A Lee, Gustavo Quiros, and Ankit Shukla. Behavior trees with dataflow: Coordinating re- active tasks in lingua franca. In Proceedings of the 2024 IEEE/ACM 4...

    2024

  20. [28]

    Behaverify: verifying temporal logic specifications for behavior trees

    Serena Serafina Serbinowska and Taylor T Johnson. Behaverify: verifying temporal logic specifications for behavior trees. In International Conference on Software Engineering and Formal Methods , pages 307–323. Springer, 2022

    2022

  21. [29]

    Parameterizing behavior trees

    Alexander Shoulson, Francisco M Garcia, Matthew Jones, Robert Mead, and Norman I Badler. Parameterizing behavior trees. In Motion in Games: 4th International Conference, MIG 2011, Edinburgh, UK, November 13-15,

    2011

  22. [30]

    Adding neural network con- trollers to behavior trees without destroying performance guarantees

    Christopher Iliffe Sprague and Petter ¨Ogren. Adding neural network con- trollers to behavior trees without destroying performance guarantees. In 2022 IEEE 61st Conference on Decision and Control (CDC) , pages 3989–

    2022

  23. [2011]

    Springer, 2011

    Proceedings 4, pages 144–155. Springer, 2011

    2011

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.