Belief–Desire–Intention Software Model¶
A BDI software model organizes an agent's information, candidate objectives, and persisting intentions through an interpreter that selects and revises action as events occur.
Core Idea¶
A belief–desire–intention (BDI) software model is an architecture for an acting software agent. It uses beliefs as the agent's revisable information about its world, desires as candidate objectives it may pursue, and intentions as courses it has selected and keeps operative across decisions. An interpreter relates those attitudes to events, available actions or plans, execution, and revision. The architectural question is not whether the three words appear in code, but whether information and possible goals guide choice while adopted intentions constrain later choice without making the agent unable to react.[1][2]
The three attitudes need not be stored in three literal tables. Candidate objectives can be generated when needed, and a practical implementation may use goals, events, plan bodies, and intention stacks. The model distinguishes possible objectives from those adopted for pursuit; it also distinguishes choosing a course from executing it. A commitment policy determines when an intention persists, succeeds, becomes impossible, or should be reconsidered as new events arrive. The exact data structures, scheduling policy, and degree of plan construction vary across implementations.[1][2][3]
Structural Signature¶
- Agent belief state — information. Represented, revisable information about the environment makes action selection sensitive to what the agent currently takes to be true. Beliefs may be mistaken; removing this role leaves no informational basis for context-sensitive choice.[1][2]
- Candidate objectives — motivation. Possible goals supply alternatives for deliberation and may conflict. They may be stored as desires or generated on demand. Without them, the controller has no goal-directed basis for selecting a course; treating every desire as an adopted goal erases an important selection step.[1]
- Intention state and commitment policy — continuity. An adopted course remains relevant across interpreter cycles, subject to conditions for completion, abandonment, suspension, or reconsideration. Remove this role and the agent either repeatedly starts choice afresh or merely runs a fixed reactive rule; the distinctive BDI commitment problem disappears.[1][2]
- Event- and context-sensitive option selection — deliberation. Internal or external changes, current beliefs, and available actions or procedures yield options from which a course can be chosen. An event queue and contextual plan library are practical realizations, not mandatory representations of every BDI specification.[1][2]
- Execution and state revision — operation. The interpreter acts from an intention, processes new information, and revises beliefs and commitments; candidate goals can be updated or regenerated as needed. Without action and revision, the three attitudes are a static taxonomy rather than a software-agent controller.[1][2]
- Procedural resources — common implementation means. PRS-style knowledge areas and AgentSpeak-style plans supply executable, often hierarchical means for an adopted goal. A fixed plan library is common in practical interpreters but not a universal theorem about BDI; removing one particular library disables that implementation, not every possible BDI model.[1][2][3]
What It Is Not¶
The software model is not the philosophical account of human practical reasoning from which its commitment idea draws inspiration. The existing Belief–Desire–Intention Model entry addresses that higher-level theory; this entry addresses the organization and operation of a software agent. Nor is every formal BDI specification automatically this software architecture: formal logic may describe possible attitudes without supplying an operating interpreter.[1]
It is not three variable names plus a loop. A reactive program can hold a belief, desire, and intention field while ignoring them when it chooses an action. A real BDI software model relates information, candidate objectives, persisting commitments, and event-sensitive execution. The model is also not defined by an unchanging stock of fully written plans: PRS can interleave partial plan formation and action, and abstract BDI specifications do not require one plan-library representation. First-principles invention of entirely new procedures, however, should not be promised by a particular library-based interpreter merely because it is called BDI.[1][2]
Scope of Application¶
BDI architecture applies literally to software agents whose selected courses persist while a changing environment presents new information or tasks. The 1987 Procedural Reasoning System (PRS) used a belief database, goals, knowledge areas, an interpreter, and an active-process stack; its research robot Flakey was tested on route navigation and interruption for a keyboard-simulated jet fault. The fault was simulated, and the paper's tool-retrieval discussion is an envisaged task, not an observed physical retrieval.[2]
The 1995 OASIS air-traffic-management research system supplied a different setting: aircraft agents and global agents processed arrival and wind information, with schedule commitments reconsidered when the agent no longer believed the next aircraft could meet its assigned estimated arrival. It was undergoing parallel evaluation at Sydney airport while receiving live radar data. The account does not establish that OASIS issued authoritative live control directions. These two settings share the attitude/interpreter organization despite different bodies of procedures and physical stakes.[1]
Clarity¶
“Desire,” “goal,” and “intention” can be used casually as synonyms, but that collapses the architecture's decision points. A desire is a possible outcome; an intention is a selected course with some persistence. A practical system's goal may name a task that triggers a procedure, yet it should not be assumed to represent every candidate desire or to be an intention already under execution. Asking which objectives are merely available and which have been adopted clarifies what the agent will do when a new event arrives.[1][2]
A second ambiguity concerns Representation. Rao and Georgeff allow desires to be generated instantaneously rather than held in a separate data structure. An implementation can therefore qualify because its operations distinguish informational, motivational, and committed roles, even if only some roles have explicit stored objects. Conversely, a data structure labeled intention is insufficient if it never constrains later deliberation.[1]
Manages Complexity¶
A reactive agent can face many facts, feasible objectives, events, procedural alternatives, and incomplete tasks. The BDI map compresses them into questions about what is believed, what could be pursued, what is currently committed, which options are available, and when to act or reconsider. This organization helps locate errors: wrong information calls for belief revision, incompatible objectives for deliberation, and an obsolete adopted course for intention reconsideration.[1]
The map does not eliminate implementation complexity. A PRS interpreter still needs trigger conditions, context tests, hierarchical steps, and scheduling. OASIS still needs aircraft-specific and global information. The benefit is that these details can be compared by their function in the architecture rather than treated as unrelated program features. Plan-library organization is one means for handling procedural scale, not a constitutive rule for every BDI agent.[2][1]
Abstract Reasoning¶
To assess a claimed BDI agent, trace one event through the system. What new information enters its beliefs? Which candidate objectives arise or become infeasible? Which available responses are considered? Which course becomes an intention, and what rule allows it to persist or be dropped? Finally, does the agent perform an action and revise its state? If the named attitudes do not change action selection or commitment, the claim is merely terminological.[1]
A changing estimated arrival time in OASIS illustrates the inference. A sequencer can keep a chosen landing order while it believes the assigned arrival can be met; if it no longer believes the next aircraft can meet that time, its policy warrants reconsideration. The inference is neither “always replan” nor “always persist.” In PRS, a simulated urgent fault could interrupt current navigation. Those examples show why observing both an ordinary cycle and an exceptional event is more informative than inspecting a static list of goals.[1][2]
Knowledge Transfer¶
The architecture transfers literally among software-agent applications when their agent state, goal choice, commitment, and interpreter relations remain present. A robot controller and an air-traffic research agent can both use BDI organization, although their sensors, objectives, knowledge areas, constraints, and validation standards differ. Copying a robot's plan library into an aviation setting would not itself transfer a working solution.[2][1]
Outside software, Bratman's practical-reasoning account helps explain why intention can limit endless reconsideration, but the software model's event interpreter and execution machinery do not thereby become a universal account of human action. Conversely, invoking “BDI” to describe a human team without executable agent organization is analogy to this software architecture. The broader live genus is Software Architecture; the named BDI method remains tied to software-agent operation.[1]
Examples¶
Canonical: PRS-controlled Flakey research robot¶
Georgeff and Lansky's PRS agent belief state was a database of current information. The system's candidate objectives included route-navigation tasks and an urgent response to a keyboard-simulated jet fault; the paper discusses tool retrieval as an envisaged scenario rather than a result of the test. Intention state and policy appeared in active knowledge areas on a process stack, where a higher-priority task could interrupt current work. Event- and context-sensitive option selection invoked knowledge areas according to goals and beliefs. The interpreter executed and revised steps as information or subgoals changed. Its procedural resources were partial, hierarchical knowledge areas. The observed warrant is research navigation and simulated interruption, not operation during a real space-station emergency.[2]
Mapped back: belief database → route and simulated-fault objectives → interruptible process-stack intentions → condition-invoked knowledge areas → interpreter action and revision → hierarchical procedures.
Applied: OASIS parallel air-traffic evaluation¶
Rao and Georgeff describe OASIS belief information from aircraft, wind, arrival estimates, and live radar received during parallel airport evaluation. Candidate objectives concerned feasible arrival times and landing sequences. The sequencer's intention policy held a schedule until it believed all aircraft had landed in sequence or no longer believed the next aircraft could meet its assigned estimated arrival. Option selection used written plan and trajectory options; an interpreter handled events and revised schedule and action possibilities. Procedural resources supplied the plan bodies. These roles were evaluated alongside live airport operations, but the source does not show OASIS exercising authoritative live control.[1]
Mapped back: aircraft and wind information → feasible arrival and sequence objectives → defeasible schedule intention → plan/trajectory choice → event-driven evaluation and revision → written procedures.
Structural Tensions¶
Deliberation time versus action time. Reconsidering every new option can improve responsiveness to changing information but consumes time that a real-time agent could use to act. Persisting with a chosen course saves decision time but can carry an obsolete plan forward. A system that maximizes both is impossible when computation and deadlines are finite. Leaning toward deliberation adds decision overhead; leaning toward action risks stale commitments. Diagnostic question: which change is large enough that the expected cost of staying the course exceeds the time cost of reconsidering?[1]
Commitment stability versus reactivity. A persisting intention coordinates multi-step action, yet urgent events and impossible goals require interruption or abandonment. Dropping an intention at every disturbance causes thrashing; never dropping it blocks urgent response. PRS's simulated-fault interruption and OASIS's infeasible-arrival rule show different triggers for release. Diagnostic question: which success, impossibility, or priority condition justifies suspending or abandoning this particular course?[2][1]
Structural–Framed Character¶
This entry sits toward the framed, domain-specific side of the spectrum even though its internal organization is structural. Evaluative weight enters through the agent's objective and commitment policy: a good choice depends on task priorities and timing, not on the BDI label alone. Human-practice dependence is substantial because people define goals, procedures, and acceptable interruptions. Institutional origin lies in practical-reasoning research and software-agent engineering; no one implementation fixes the entire class. Vocabulary travel is possible for belief, desire, and intention, but the terms acquire specific operational roles in a software interpreter. Import versus recognition matters: one can recognize the same architecture in robot and airport research agents by tracing its roles; applying the software-model name to a human organization imports an analogy. The portable question of how commitments constrain action may travel, but this named model includes domain-bound execution machinery. Its character: a software architecture that makes practical-reasoning distinctions operational within bounded agent implementations.[1][2]
Structural Core vs. Domain Accent¶
The structural core is a relation among revisable information, possible goals, adopted commitments, and event-responsive action. Software Architecture is the live genus because those elements and their organization govern the behavior of a software system. The domain accent is the software-agent interpreter, its state and procedure representations, event handling, execution cycle, and programming choices. PRS stacks and Jason language features vary within that domain; they are not universal parts of the core.[1][2][3]
The entry does not clear the Prime bar. Removing executable agent organization leaves a broad practical-reasoning question, not the BDI software model. The philosophical BDI model is a historical and conceptual source, not this node's taxonomic parent. Whether the information–candidate objective–persisting commitment–reconsideration pattern recurs outside software as a distinct Prime remains a future admission question; the present robot and airport evidence does not establish it. That reach is not earned by stripping “software” from this name. The strict Software Architecture edge records the necessary genus of the admitted instances, while the content of the BDI attitudes supplies the differentia.
Instantiates / Related Primes¶
This entry is a kind of Software Architecture.
The staged DAG asserts one strict subsumption edge to Software Architecture. Every admitted BDI software model organizes software-agent elements and relations, while many software architectures lack BDI attitudes. The edge is a kind-of relation, not a claim that the BDI model is a component inside every software architecture.
The live Belief–Desire–Intention Model records the higher-level philosophical/practical-reasoning identity that inspired this architecture; similarity of words and historical influence do not prove duplicate identity or an all-instance parent edge. Formal Model is declined because a practical program need not expose an explicit mathematical or logical specification. Prime Commitment is declined as a direct graph parent because its live identity requires a relying-party and breach relation that a software intention stack need not have. Agency is thematic background, with no separate direct prerequisite established here.[1]
Relationships to Other Abstractions¶
Current abstraction Belief–Desire–Intention Software Model Domain-specific
Parents (1) — more general patterns this builds on
-
Belief–Desire–Intention Software Model is a kind of Software Architecture Domain-specific
A BDI software model is a specific organization of software-agent state, choice, commitment, and execution.Every admitted BDI software model organizes an agent's information, candidate objectives, intention commitments, interpreter, and action as consequential software elements and relations. Software Architecture supplies this system-level genus; BDI adds its distinctive practical-reasoning organization. Many software architectures do not implement BDI, making subsumption strict.
Hierarchy path (1) — routes to 1 parentless root
- Belief–Desire–Intention Software Model → Software Architecture
Neighborhood in Abstraction Space¶
Belief–Desire–Intention Software Model sits in a sparse region of the domain-specific corpus (94th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2551 abstractions)
Nearest neighbors
- Reinforcement learning — 0.82
- Inferential Theory of Learning — 0.80
- Simulation — 0.78
- Use Case — 0.77
- Frege's Puzzles — 0.77
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
Philosophical BDI model: explains practical reasoning at a higher level; ask whether the subject is an operating software-agent organization. Reactive rule engine: maps events to actions, but may lack persisting intentions that constrain later deliberation. Fixed workflow engine: executes a procedure, but may lack distinct candidate goals and event-sensitive reconsideration. Formal BDI logic: can axiomatize attitudes without building an interpreter. Jason: a particular AgentSpeak-based implementation with additional language and multi-agent features, not the definition of every BDI software architecture.[1][2][3]
References¶
[1] Anand S. Rao and Michael P. Georgeff, “BDI Agents From Theory to Practice”, Proceedings of the First International Conference on Multiagent Systems (1995), printed pp. 312–319, especially pp. 313–318. The source title page prints “BDI Agents: From Theory to Practice”; the linked transcription omits the colon so the reference binder retains the complete work identity. Primary full text for the abstract and practical BDI interpreters, commitment policies, and OASIS parallel evaluation. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r ↩s ↩t ↩u ↩v ↩w ↩x ↩y ↩z
[2] Michael P. Georgeff and Amy L. Lansky, “Reactive Reasoning and Planning”, Proceedings of the Sixth National Conference on Artificial Intelligence (1987), printed pp. 677–682, especially §§3.1–3.4 and §5. Primary full text for PRS structure, interleaved partial planning and execution, and the reported Flakey research test. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p ↩q ↩r
[3] Jason project, “Jason” official documentation, “About Jason” and “Jason Agent Language.” Primary project description of an AgentSpeak-based BDI interpreter; cited only for an implementation variant, not comparative efficacy. registry ↩a ↩b ↩c ↩d