AI Agent Architecture Under the Microscope: From the PDA Loop to the BDI Model and Design Patterns

In the first article of this series, we broke down the concept of an intelligent agent as a system that interacts with its environment to achieve a specific goal. Now, it's time to go a level deeper and look at its internal architecture. Instead of treating the agent as a black box, we will see how to translate theory into concrete components and code structure.

We will walk through the classic execution loop, look at the BDI (Belief-Desire-Intention) model, and discuss design patterns that save developers from drowning in spaghetti code. This is still a solid dose of engineering theory, but grounded very close to practice.

The Heart of the System: The Perceive–Decide–Act (PDA) Loop

From an architectural perspective, an agent is not a magical, monolithic algorithm, but a system of closely cooperating components. Its foundation is the continuously running Perceive-Decide-Act (PDA) loop, which defines how it interacts with the environment.

• Perceive: Receiving stimuli from the environment. These can be user queries (text, clicks), readings from physical sensors, or data flowing from external APIs.
• Decide: Processing the gathered information, analyzing the state, and choosing the optimal action based on implemented logic, rules, or models.
• Act: Executing the chosen action using effectors, function calls, or operations on external systems.

In its simplest form, this boils down to an infinite loop in code:

while True:
    percept = perceive()
    decision = decide(percept)
    act(decision)

Although this pseudocode looks trivial, the devil is in the implementation details of each of these three functions. A lot of magic can happen inside them.

Evolution of Architectures: From Reflex to Learning

Depending on the complexity of the tasks, an agent's architecture can take various forms. It is worth knowing these classes of systems to choose the right tool for the problem.

Simple Reflex Agents

This is the simplest possible architecture, operating on a direct stimulus-response basis. The agent does not maintain state or plan for the future—it relies solely on rigid "if X, then Y" rules.

• if temperature > 25 → turn on air conditioning,
• if distance to wall < 10 cm → turn left.

def decide(percept):
    if percept == "przeszkoda":
        return "skrec_w_lewo"
    else:
        return "idz_prosto"

The advantage of this approach is extreme speed and simplicity. The disadvantage is a complete lack of flexibility, no memory, and the inability to pursue higher-level goals.

Stateful / Model-Based Agents

One step up are agents that can store information about the past. They possess an internal world model that allows them to track changes, even when a given element of the environment is not directly visible at the moment (e.g., a robot remembers which areas it has already visited). The decision here depends on both the current perception and the stored state.

Goal-Based Agents

In this architecture, the agent does not just react to the state of the environment but strives toward a specific, defined goal. Examples of goals include reaching point (X, Y) or minimizing operational costs. The system must have a representation of this goal and a planning mechanism that evaluates which sequences of actions bring it closer to success.

Utility-Based Agents

When a goal can be achieved in multiple ways, a simple binary division of "goal achieved / not achieved" is not enough. These agents use a utility function that evaluates the "quality" or "cost" of individual states. The agent aims to maximize this value—for example, balancing delivery time against a drone's energy consumption, or maximizing the likelihood of user satisfaction in a recommendation system.

Learning Agents

The most advanced group, capable of independently modifying their behavior based on gathered experiences. This architecture contains a dedicated learning module that analyzes successes and failures and updates the action strategy accordingly (e.g., through a reward and punishment mechanism). This is the perfect place to apply algorithms such as Q-learning, deep reinforcement learning, or adaptive control strategies.

The BDI Model: Belief, Desire, Intention

One of the most elegant and proven approaches to modeling agent behavior is the BDI (Belief-Desire-Intention) architecture. It is based on the philosophical concept of human action and beautifully organizes the architecture of AI systems:

• Beliefs: The agent's internal knowledge about the world and itself. These are facts that the agent believes to be true (e.g., "the warehouse door is closed", "the user is logged in").
• Desires: All potential goals that the agent would like or could achieve (e.g., "deliver the package", "minimize delays"). Desires can often conflict with one another.
• Intentions: The specific desires that the agent has decided to actively pursue at any given moment. These are goals translated into a concrete action plan (e.g., "currently driving to point A", "currently generating a report").

A Human Example of BDI

Imagine a simple real-life scenario:

• Beliefs: It is 7:45 AM. I have an important meeting at 8:00 AM in an office that is 15 minutes away.
• Desires: I want to get to the meeting on time. I also want to grab a hot coffee on the way (which will take an extra 10 minutes).
• Intention: Since my beliefs (lack of time) rule out achieving both desires, I choose the one with the higher priority: I skip the coffee and leave the house immediately.

In software architecture, the BDI model is implemented by dividing the system into modules responsible for updating beliefs (processing perception), generating goals, selecting intentions (planning), and executing them physically.

Design Patterns in Agent Architecture

How do we translate these concepts into clean code? In engineering practice, four proven design patterns are most commonly used:

Event Loop

This is an ideal solution for conversational agents, bots, or systems operating continuously (24/7). The agent listens for events, queues them, and processes them asynchronously.

while True:
    event = pobierz_zdarzenie()
    state = zaktualizuj_stan(event)
    action = wybierz_akcje(state)
    wykonaj_akcje(action)

Rule Engine

This works great in reactive systems. It allows you to separate business logic (rules) from the execution engine itself, making it easier to modify the system later without touching the application core.

rules = [
    {"if": lambda s: s["temperatura"] > 25, "then": "wlacz_klime"},
    {"if": lambda s: s["bateria"] < 10, "then": "idz_do_ladowarki"},
]

def decide(state):
    for rule in rules:
        if rule["if"](state):
            return rule["then"]
    return "nic_nie_rob"

Planner + Actions

Patterns dedicated to goal-oriented agents. We separate a distinct Planner module, which generates a sequence of steps based on the goal and state of knowledge, and a set of atomic Actions that the agent can physically execute. Planning can be based on classic graph algorithms (e.g., A*), formal logic (STRIPS), or LLM calls, where GPT serves as the main planner.

Blackboard Pattern

A key pattern in multi-agent systems. Agents are integrated around a common shared memory space (the blackboard). Agents can independently read data from it, process it, and write back results, which drastically simplifies communication and coordination within the team.

Agent Template in Python

The code below is a simplified but architecturally complete BDI agent template in Python. It demonstrates how to combine perception, knowledge updates, deliberation (choosing goals and intentions), and action planning into a cohesive whole.

class Agent:
    def __init__(self, initial_beliefs=None):
        self.beliefs = initial_beliefs or {}
        self.goals = []
        self.intentions = []

    def perceive(self, environment):
        percept = environment.get_state()
        self.update_beliefs(percept)

    def update_beliefs(self, percept):
        # update knowledge about the world
        self.beliefs.update(percept)

    def deliberate(self):
        # choose goals and intentions – BDI logic can go here
        self.goals = self.generate_goals(self.beliefs)
        self.intentions = self.filter_goals(self.goals)

    def decide(self):
        # choose a specific action based on intentions
        if not self.intentions:
            return None
        return self.plan_action(self.intentions[0])

    def act(self, action, environment):
        if action:
            environment.apply_action(action)

    def step(self, environment):
        self.perceive(environment)
        self.deliberate()
        action = self.decide()
        self.act(action, environment)

This skeleton serves as an excellent starting point for building more advanced systems, which we will equip with long-term memory or language model integration in the next steps.

Common Pitfalls in Agent Design

When implementing agent systems, it is easy to fall into architectural traps. Here are the four most common mistakes you need to watch out for:

• Lack of layer separation: Combining code responsible for data retrieval (perception), decision logic, and physical action execution into a single, giant `if-else` structure. Such code quickly becomes unmaintainable.
• Poor state management: Extremes are dangerous. A stateless agent cannot perform complex tasks, while an agent that stores too much unfiltered information quickly "drowns" in information noise. State must be designed consciously.
• Ignoring the concept of a goal: Trying to force a reactive agent to perform complex, multi-step tasks. Without an explicit representation of goals and intentions, the system will quickly get stuck in a loop of useless actions.
• Lack of modularity: Designing the system in a way that makes it impossible to easily add new actions, sensors, or integrations with new data sources without deeply modifying the existing code.

Summary

A well-designed architecture is key to a stable and scalable agent system. The Perceive-Decide-Act loop provides us with an operational framework, models like BDI help structure the machine's thought processes, and proven design patterns (such as the Event Loop or Blackboard) facilitate clean implementation in code.

In the next article, we will move from theory to practice—we will write our first fully functional environment-exploring agent in Python from scratch, and then step-by-step add memory and LLM integration to it.