Agent Architecture Styles: Reactive vs. Deliberative vs. Hybrid Systems

An agent, in the sense this whole course uses the word, is an LLM-driven system that perceives its environment, reasons about a goal, takes actions — often by calling tools — to pursue that goal, and then observes the result before continuing. [GROUND TRUTH] (Sources/ncp-aai/domain-1-agent-architecture-design.md): unlike a single one-shot prompt that produces one output and stops, an agent runs a loop and carries some state across iterations of that loop. That loop property is what separates "an agent" from "a really good autocomplete." A one-shot summarizer that reads a document and returns a summary is not an agent by this definition, however impressive the summary is, because there is no loop: no observation feeding back into a next decision.

Once you accept that an agent is fundamentally a loop, architecture style becomes a question about what happens inside that loop between perceiving and acting. Some agents skip straight from perception to action with nothing in between worth calling "reasoning." Others insert a genuine planning step, weighing multiple possible action sequences against an internal model of how the world will respond, before committing to one. That difference — is there a world model in the loop, or isn't there — is the entire content of the reactive/deliberative/hybrid distinction, and everything else in this lesson is detail layered onto that one fork.

It helps to be precise about what "world model" means here, because the phrase can sound grander than the underlying idea. A world model does not have to be a full physics simulator or a hand-built ontology of the domain. It can be as modest as an internal representation of "here is the current state of the task, here are the steps still remaining, here is what I expect to happen if I take this action next." The defining property is not sophistication — it is that the model exists before the action is chosen and is used to evaluate candidate actions against some notion of a goal, rather than the action being chosen directly from the current stimulus with no such intermediate step.

L1 — Intuition

A reactive agent behaves the way a thermostat behaves, scaled up to language and tool use: a stimulus arrives, a rule or a learned mapping fires, and a response goes out, with nothing resembling planning or lookahead in between. If the room is cold, turn on the heat. If a user's message contains a known keyword, route to a known handler. If a sensor reads an obstacle two meters ahead, turn. There is no step where the system asks "what will happen three moves from now if I do this" — the response is a direct function of the current stimulus, full stop.

L2 — Mechanism

Mechanically, a reactive agent's decision function can be sophisticated — it might be a large language model applying rich, context-sensitive judgment to the current input — but the architectural signature is that the judgment is applied once, to the current state, with no internal simulation of downstream consequences feeding back into the choice. [GROUND TRUTH] (Sources/ncp-aai/domain-1-agent-architecture-design.md): NVIDIA's own framing describes reactive agents as responding directly to stimuli with no internal model of the world, which is exactly this "one pass, current state only" signature. A reactive customer-support triage agent, for instance, can be very good at reading a ticket and picking the right specialist queue on the first read — that is a hard, genuinely intelligent judgment call — while still being reactive in the architectural sense, because it never asks "if I route this here, and that turns out to be wrong, what happens two steps later," it just makes the best call it can with the current ticket and moves on.

L3 — The edge case that trips people up

The edge case worth sitting with is that "reactive" does not mean "dumb" or "rule-based" in the pejorative sense that phrase sometimes carries. A reactive agent running a frontier LLM against a rich prompt can outperform a deliberative agent running a weaker model, on many tasks, simply because the LLM's single-pass judgment is that good. The architectural label describes the shape of the decision process — one pass, no lookahead — not the intelligence or sophistication of what happens inside that one pass. This distinction matters directly for scenario questions: a described system that makes a single, context-sensitive LLM call per incoming request and never simulates or compares multiple future action sequences is reactive, regardless of how well it performs, and the correct answer to "which architecture style is this" does not change just because the described system sounds impressive.

The trade-off that comes with this shape is exactly what you would expect from skipping lookahead: reactive agents are fast and structurally simple, because there is no planning step to run, but they genuinely struggle with goals that require several coordinated steps where an early choice constrains what is even possible later. A reactive agent booking a flight can pick a plausible-looking option for the current search, but it has no built-in mechanism for realizing that the option it is about to pick will make a later, still-unstated constraint (a connecting-flight timing requirement three steps into the conversation) impossible to satisfy — because nothing in its design looks that far ahead in the first place.

L1 — Intuition

A deliberative agent inserts exactly the step a reactive agent skips: before committing to an action, it builds or updates an internal model of the current situation, generates or considers candidate courses of action, and evaluates those candidates against that model before picking one. Where a reactive agent's loop is perceive → act, a deliberative agent's loop is closer to perceive → model → plan → act, with the middle two steps doing real work rather than being a formality.

L2 — Mechanism

[GROUND TRUTH] (Sources/ncp-aai/domain-1-agent-architecture-design.md): NVIDIA's material describes deliberative agents as planning over an internal model before acting, and names the corresponding trade-off directly — deliberative agents handle complex goals well, at the cost of being slower and heavier than a reactive equivalent. The "heavier" part is not incidental. Maintaining an internal model, generating multiple candidate plans, and scoring them against that model all consume compute and latency that a reactive agent's single pass never spends. A deliberative trip-planning agent that considers three different flight-and-hotel combinations, simulates the total cost and total travel time for each, and picks the best-scoring combination is doing real planning work that takes measurably longer than a reactive agent that just returns the first result matching the stated filters.

L3 — The edge case that trips people up

The trap worth naming explicitly is assuming "deliberative" requires a hand-built symbolic planner or a classical AI-style search algorithm. In modern agent systems, the "internal model" a deliberative agent plans over is frequently just the LLM's own working representation of the task state, built and updated through its context window and intermediate reasoning steps, rather than a separate formal model with explicit states and transitions. What makes an agent deliberative is not the implementation technology — it is that a plan-then-act structure genuinely exists in the loop, evaluated against some internal representation, before an action is committed. A described system where an LLM is explicitly prompted to "consider several possible next steps, evaluate the likely outcome of each, and then choose" is deliberative even if the "model" it plans over is nothing more elaborate than its own reasoning trace, because the plan-before-act structure is the defining property, not the sophistication of the substrate underneath it.

The corresponding failure mode is the mirror image of a reactive agent's failure mode: a deliberative agent that spends real latency simulating and comparing candidate plans for a task simple enough that the first reasonable option was always going to be fine is paying a real cost — slower responses, more tokens, more compute — for foresight the task never needed. Deliberation is not free, and applying it to every decision regardless of whether the decision benefits from lookahead is itself a design mistake, just one in the opposite direction from under-planning.

L1 — Intuition

A hybrid architecture combines fast, reactive responses for the situations that need speed with slower, deliberative planning for the situations that need foresight — and the important word in that sentence is "combines," not "adds." A hybrid system is not a deliberative agent with a reactive fallback bolted on for emergencies, and it is not a reactive agent with an occasional planning step wedged in. It is a design that deliberately routes different kinds of decisions to different processing paths based on what each decision actually needs.

L2 — Mechanism

[GROUND TRUTH] (Sources/ncp-aai/domain-1-agent-architecture-design.md): NVIDIA's framing states plainly that hybrid architectures balance responsiveness and foresight, which is the clean way to describe what the combination is actually for. Picture an autonomous-vehicle-style agent (used here as a constructed, illustrative example rather than a specific product claim): a fast reactive path handles obstacle detection and braking, because a half-second of deliberation before braking is a half-second the situation cannot afford, while a slower deliberative path handles route selection and multi-stop trip planning, because that decision genuinely benefits from comparing several candidate routes against traffic, tolls, and timing before committing. Both paths are running inside the same overall system, and the architecture's job is to route each decision to the right one — not to run every decision through both.

L3 — The edge case that trips people up

The subtlety the exam leans on is the seam between the two paths: what decides whether a given decision goes to the fast path or the slow one? That routing logic is itself a real design choice, and it is where hybrid architectures earn their complexity. A hybrid system with a poorly designed seam can end up with the worst of both worlds — decisions that needed lookahead getting routed to the fast path (a route-planning decision handled reactively, producing a locally sensible but globally poor route), or decisions that needed speed getting routed to the slow path (an obstacle-avoidance decision waiting on a planning cycle it cannot afford). Recognizing a hybrid architecture in a scenario question, then, is not just "does this system have both a fast and a slow component" — it is "does this system route different decision types to the component actually suited to their latency and foresight requirements." A system that always runs every decision through both a reactive check and a full deliberative pass, in sequence, every time, is arguably still hybrid in a loose sense, but it has given up the responsiveness half of the whole point, since every decision now pays the deliberative path's cost regardless of whether the decision needed it.

It is worth stating the non-hierarchy point directly, because it is the single most consequential thing to take from this lesson: hybrid is not "the mature version" of reactive and deliberative, the way a senior engineer is a mature version of a junior one. It is a third answer to the same design question — how much lookahead does this agent's decisions need — for the specific case where the honest answer is "different amounts, for different decisions, within the same system." A single-purpose agent whose every decision genuinely needs the same latency-versus-foresight trade-off has no reason to be hybrid; hybrid earns its added complexity only when the decision mix actually varies.

Reading the table's middle column is the fastest way to resolve a scenario question: find the sentence in the prompt that describes the decision shape, and match it to the row whose "decision shape" cell fits, rather than reasoning from how advanced or capable the described system sounds overall.

Constructed scenario, illustrative only. Two short scenarios, worked the way a scenario question expects you to work them — find the decision shape first, then name the style.

Scenario A: A warehouse robot's obstacle-avoidance module.
Given: sensor input showing an obstacle at a measured distance and bearing.
Task: decide whether to slow, stop, or reroute around the obstacle, within
       a response budget of roughly 200 milliseconds.

Step 1 — Is there a world model built before this decision?
  No. The module receives the current sensor reading and maps it directly
  to a braking/steering response. There is no step where it constructs a
  representation of "here is the warehouse layout, here are three routes
  around this obstacle, here is the projected cost of each."

Step 2 — Is the decision shape single-pass or plan-then-act?
  Single-pass: stimulus (obstacle at X meters, Y degrees) -> response
  (slow / stop / reroute-by-Z-degrees), computed once, immediately.

Step 3 — Does the 200ms budget rule out deliberation?
  Yes — any meaningful plan-generation-and-scoring step would blow the
  latency budget for a decision this time-critical.

Conclusion: Reactive. The speed requirement and the single-pass decision
shape both point the same direction.

The second scenario deliberately picks a decision from the same constructed warehouse system, to show that architecture style is a property of the decision, not a single fixed label for "the robot" as a whole:

Scenario B: The same warehouse robot's shift-start route-planning module.
Given: a list of 40 pick locations to visit before the shift ends, and a
       known map of aisle distances.
Task: decide the order to visit the 40 locations, minimizing total travel
       distance, before the shift's first pick.

Step 1 — Is there a world model built before this decision?
  Yes — the module has to represent the aisle map and compute or compare
  candidate visiting orders against it before choosing one.

Step 2 — Is the decision shape single-pass or plan-then-act?
  Plan-then-act: several candidate route orderings are generated (or one
  is generated and iteratively improved), each is scored against the
  known map, and the best-scoring order is what the robot actually
  executes for the whole shift.

Step 3 — Does the decision's latency budget forbid planning?
  No — this decision is made once, before the shift starts, with minutes
  available rather than milliseconds, so the planning cost is affordable
  and the payoff (a meaningfully shorter shift) is real.

Conclusion: Deliberative. The same physical robot that was reactive for
obstacle avoidance is deliberative for route planning — and a robot
built with both modules, each routed to the decision type it fits, is
the hybrid architecture this lesson describes, not a fourth category.

The point of walking both scenarios inside one constructed system is the exam-relevant lesson itself: a single deployed agent can legitimately contain reactive modules and deliberative modules side by side, and the architecture-style question is almost always really asking about a specific decision inside the system, not a single label glued to the whole thing.

⭐ THE EARNED INSIGHT Reactive, deliberative, and hybrid are not three points on a maturity ladder where more sophistication always wins — they are three answers to one question, "how much lookahead does this specific decision need and can afford," and the same physical agent can legitimately hold multiple correct answers to that question for different decisions it makes. The exam trap of ranking the three styles by sophistication misses that a reactive obstacle-avoidance module operating inside a 200-millisecond budget is not an inferior, unfinished version of a deliberative one — it is the correct architecture for that specific decision, and swapping it for a deliberative module would be a worse design, not a better one, because it would blow the latency budget the decision actually has to respect.

Agent Architecture and Design is Domain 1 of the NCP-AAI blueprint, tied with Agent Development for the heaviest weight in the whole exam at 15%. [GROUND TRUTH] (Sources/ncp-aai/domain-1-agent-architecture-design.md): the domain's own scope note states this is a professional exam expecting candidates to reason about why an architecture fits a scenario, not merely recite definitions — and architecture style is the most upstream instance of exactly that expectation, because it is the first design choice every later lesson in this module builds on top of.

Expect the question shape to work in two recurring forms. The first is a short scenario — a latency-critical sensor response, a multi-step trip-planning task, a system that clearly does both — mapped to the correct style, exactly like the worked example above. The second is a trap item built from the misconception this lesson has repeatedly flagged: an answer choice that ranks the three styles by sophistication, or that calls a single-pass, LLM-driven judgment call "deliberative" purely because the underlying model is capable, or that labels a two-component system "hybrid" without checking whether it routes decisions by type. A candidate who has the three names memorized but reasons by "which style sounds smartest" rather than "what decision shape does the scenario actually describe" will pick the sophisticated-sounding wrong answer on exactly this kind of item.

Scenario questions rarely hand you the words "reactive" or "deliberative" directly — you have to derive the label from a behavioral description, and the derivation is more reliable when it follows a fixed order of checks rather than a gut read of how advanced the system sounds. Three checks, applied in sequence, resolve nearly every ambiguous case this domain tests.

The first check is the world-model check: does the description mention the system building, updating, or consulting any representation of the situation before choosing an action — a map, a set of candidate plans, a projected outcome? If nothing in the description does that, default toward reactive regardless of how capable the described model sounds, because capability and world-modeling are independent, as the previous section establishes. The second check is the timing check: does the decision get made once, immediately, from the current input, or does the description involve generating and comparing multiple options first? "Immediately" and "compares options" are close to mutually exclusive in how scenario prompts are worded, and whichever phrase appears is usually the tell. The third check, useful specifically when the first two checks disagree or are ambiguous, is the latency-budget check: does the scenario state or imply a tight time constraint (a safety-critical response, a real-time control loop) that would make any planning step actively harmful even if the system nominally has one? A described system that claims to "consider options" but operates under a hard millisecond-scale constraint is more likely being tested as a case where reactive is the correct choice despite superficially deliberative-sounding language, which is exactly the kind of inversion the exam uses to separate candidates who pattern-match keywords from candidates who reason about the actual constraint.

Running all three checks before committing to an answer costs a few seconds and resolves cases that a single keyword scan gets wrong — particularly the cases engineered specifically to make the "obviously sophisticated-sounding" answer choice the wrong one.

No, and the difference matters for exam-scenario reasoning specifically. A fallback implies the reactive path is the default and deliberation only kicks in when the reactive path fails or is unavailable — a strictly secondary role. A genuinely hybrid architecture instead routes different kinds of decisions to the path suited to them from the start, as a first-class design decision, not as an emergency backup. An autonomous-vehicle-style system's obstacle-braking module is not "falling back" to reactive behavior when deliberative route planning is too slow — reactive is simply the correct, primary architecture for that specific decision, running in parallel with a deliberative module handling a completely different decision, and neither module is subordinate to the other.

No — architecture style is about decision shape, not about how much compute or how capable the underlying model is. Running a larger, more capable LLM inside a reactive agent's single-pass decision step can make that single pass a better, more context-sensitive judgment, but it does not introduce a plan-then-act structure if none existed before. A reactive agent stays reactive, however capable its underlying model becomes, right up until the architecture actually adds a step where candidate future actions are generated and compared against an internal model before one is chosen — at which point it has become deliberative (or, if that step exists for some decisions and not others, hybrid), independent of whether the model powering it changed at all.

• Reactive, deliberative, and hybrid are three answers to one question — how much lookahead a decision needs and can afford — not a ranked maturity ladder.
• Reactive agents respond directly to stimuli with no internal world model; they are fast but structurally cannot coordinate multi-step goals, because nothing in their design looks ahead.
• Deliberative agents build or update an internal model and compare candidate actions against it before acting; they handle complex, multi-step goals well, at a real cost in speed and compute.
• Hybrid agents route different decisions to whichever path — fast reactive or slower deliberative — actually fits that decision, and the routing seam itself is a real design choice, not a formality.
• A single deployed agent can be reactive for one decision and deliberative for another; the architecture-style question in a scenario is almost always about a specific decision, not one label for the whole system.
• Model capability and architecture style are independent axes — a bigger, more capable model inside a single-pass decision step does not make that step deliberative.

Architecture style answers "how does this agent decide what to do right now," but it says nothing yet about what happens when a task needs several coordinated decisions in sequence, each one shaping what the next decision can even be. M1-02 picks up exactly there: logic trees, prompt chains, and stateful orchestration as the three concrete ways to structure that multi-step reasoning, and why an architecture that cannot swap one agent or tool for another without a full rewrite is a liability the moment requirements change.

Next: M1-02 — structuring multi-step reasoning with logic trees, prompt chains, and adaptable architecture, and why "adaptable" specifically means an individual component can be swapped without retraining the whole system.