Post cover image

July 26, 2026

LLM-Based BDI Architecture: Why AI Agents Need Commitment, Not Just Planning

“Reactive agents can respond. Deliberative agents can plan. But modern AI agents need something more — they need to stay committed to a…

By Mukund Kumar Choudhary

4 min read

"Reactive agents can respond. Deliberative agents can plan. But modern AI agents need something more — they need to stay committed to a goal even when the world changes around them."

Every Architecture Solves One Problem and Reveals Another

In the previous two articles, we explored two different approaches to building AI agents.

The Reactive Architecture was designed to solve one problem:

Speed.

Instead of spending time reasoning, the agent simply observes the environment and immediately responds.

Observe
     ↓
Act

This approach is perfect for applications where every request is independent.

For example:

  • Answering FAQs
  • Translating text
  • Summarizing documents
  • Retrieving information

The agent receives an input, produces an output, and the interaction ends.

For these problems, reactive systems are simple, fast, and efficient.

But Modern AI Agents Are Different

Today's LLM agents don't just answer questions.

They perform tasks.

Imagine asking an AI agent:

"Deploy my application to Kubernetes and make sure it's running successfully."

This isn't a single action.

The agent must:

  • Deploy the application
  • Verify the pods
  • Check application health
  • Fix deployment issues if they occur
  • Notify the user when everything is working

Now the agent is responsible for achieving an outcome, not simply responding to an event.

This is where Reactive Architecture begins to struggle.

Where Reactive Architecture Falls Short

Suppose the deployment begins.

Everything seems fine.

Suddenly Kubernetes reports:

ImagePullBackOff

A reactive agent immediately responds.

ImagePullBackOff
        ↓
Push New Image

Later another issue appears.

Readiness Probe Failed

Again the agent reacts.

Readiness Probe Failed
            ↓
Restart Pods

Then another issue appears.

Database Connection Failed
            ↓
Reconnect Database

Each reaction is technically correct.

But notice something important.

The agent is never asking:

"Am I still moving toward successfully deploying the application?"

It only knows:

"Something happened. Let me react."

The bigger objective is missing.

Reactive Architecture solves the problem of speed, but it doesn't give the agent a sense of purpose.

Deliberative Architecture Solved That Problem

To overcome this limitation, Deliberative Architecture introduced planning.

Instead of immediately reacting, the agent first understands the objective and creates a plan.

For our deployment example, the plan might look like this.

Deploy Application
        ↓
Verify Pods
        ↓
Check Health Endpoint
        ↓
Notify User

Now every action contributes toward a larger objective.

This is a huge improvement.

The agent no longer performs isolated actions.

It follows a strategy.

But Planning Introduced Another Challenge

Real-world environments rarely stay stable.

Suppose the deployment fails because of an ImagePullBackOff error.

A deliberative agent evaluates its plan.

It may conclude:

"My current plan is no longer valid."

It creates a new plan.

Build Image
      ↓
Push Image
      ↓
Deploy Again
      ↓
Verify Pods

Later another issue appears.

The readiness probe fails.

Again, the agent evaluates the plan.

Again, it may generate a new one.

As environments become increasingly dynamic, repeatedly stopping to rethink the entire workflow becomes expensive.

Most of the original plan is still useful.Only one step has changed.

Planning solved the problem of purpose.

But it introduced unnecessary replanning.

The Missing Piece

At this point, researchers realized something important.Reactive agents know how to respond.Deliberative agents know how to plan.Neither knows what they have committed to achieving.

Think about how humans behave.Suppose you're driving to work.Suddenly there's heavy traffic.You don't abandon your goal of reaching the office.You don't rethink your entire day.You simply choose another route.Your actions change.Your commitment doesn't.Modern AI agents need exactly the same capability.

They need to understand:

  • What do I currently know?
  • What am I trying to achieve?
  • What have I already committed to doing?

This idea became the foundation of the Belief–Desire–Intention (BDI) Architecture.

Why LLMs Make BDI More Powerful

Classical BDI introduced these ideas decades ago.

But classical systems depended on symbolic rules and predefined plan libraries.

Developers had to manually define:

  • beliefs
  • plans
  • decision rules
  • possible situations

That worked well for robots operating in predictable environments.

Modern AI agents work in a completely different world.

They interact with:

  • Kubernetes
  • APIs
  • Databases
  • GitHub
  • Web Search
  • Enterprise tools

The environment changes continuously.

Predefined rules simply don't scale.

This is where Large Language Models transformed BDI.

LLM-Based BDI in Action

Suppose our deployment agent receives the same request.

"Deploy my application to Kubernetes and make sure it's running successfully."

Instead of blindly reacting or constantly rebuilding plans, the LLM continuously maintains three internal states.

Beliefs

Everything the agent currently knows.

For example:

Deployment Failed
Reason = ImagePullBackOff
Docker Image Exists
Registry Reachable
Pods Not Running

Unlike classical systems, these beliefs are continuously updated from tool outputs, APIs, logs, memory, and conversation context.

Desires

The overall objective never changes.

Successfully deploy the application.

The LLM may also infer supporting goals.

  • Fix deployment issues
  • Verify application health
  • Notify the user after success

Intentions

Intentions represent what the agent has committed to doing next.

Initially they might be:

Deploy Application
      ↓
Verify Pods
      ↓
Check Health
Now imagine Kubernetes reports:
ImagePullBackOff

The agent doesn't abandon its overall objective.

Instead, it updates its beliefs.

Belief Updated
Deployment Failed
Reason = ImagePullBackOff

Then it adjusts only the affected intention.

Build Correct Image
        ↓
Push Image
        ↓
Redeploy
        ↓
Continue Verification

The overall commitment never changes.

The goal remains:

Successfully deploy the application.

Only the next actions evolve based on new information.

The LLM-Based BDI Loop

                     User Request
                           │
                           ▼
                Build / Update Beliefs
          (What do I currently know?)
                           │
                           ▼
                 Identify Desires (Goals)
      (What do I want to achieve? There may be many.)
                           │
                           ▼
                     Deliberation
 (Which desire(s) should I commit to right now?)
                           │
                           ▼
                      Form Intentions
 (What am I committed to achieving?)
                           │
                           ▼
                   Generate a Plan
 (How can I achieve this intention?)
                           │
                           ▼
                     Execute Actions
                           │
                           ▼
                  Observe the Results
                           │
                           ▼
                     Update Beliefs
      (Did something change in the world?)
                           │
             ┌─────────────┴──────────────┐
             │                            │
             ▼                            ▼
   Small environmental change?     Goal / Priority changed?
             │                            │
            Yes                          Yes
             │                            │
             ▼                            ▼
     Repair / Adjust Plan          Re-deliberate
 (Keep the same intention)         Choose new intention
             │                            │
             └──────────────┬─────────────┘
                            ▼
                     Continue Execution

This loop allows the agent to adapt continuously without losing sight of its objective.

Final Thoughts

Each architecture in this series exists because the previous one solved one problem while exposing another.

  • Reactive Architecture gave AI agents speed, but they lacked long-term purpose.
  • Deliberative Architecture introduced planning, but dynamic environments made constant replanning expensive.
  • LLM-Based BDI Architecture adds commitment. The agent continuously updates what it knows, adapts its next actions, and stays focused on the original goal.

Rather than reacting blindly or replanning everything from scratch, modern LLM agents maintain an internal understanding of what they know, what they want, and what they're committed to achieving.

That is what makes them far more capable in real-world, constantly changing environments.