Agent Architecture Patterns

The first "AI" feature I shipped was a support-triage widget inside an internal support dashboard. Tickets came in, the widget scanned each message for keywords, and routed the conversation to a canned response. It worked beautifully — until a customer wrote "my thingy stopped doing the thing it does." Zero keyword matches. The widget returned "Sorry, I can't help with that," and the ticket sat unrouted for hours.

I had built a reactive agent: a system that maps inputs directly to outputs through a fixed rule set, with no capacity to reason about what it does not already know. The rules were a hardcoded model of the world as it existed the day I wrote the code. The world moved on; the rules did not.

Think of a reactive agent like a vending machine. You press B4 and you get a granola bar. But if someone asks for "something healthy and crunchy," the machine has no response — it only understands button codes. A deliberative agent is more like a skilled consultant: you describe what you need in plain language, and they reason about the best answer before responding.

That gap — hardcoded stimulus-response versus full-context reasoning — is the architectural divide every other module in this path builds on.

A reactive agent produces an output the moment it sees an input. There is no memory, no reasoning, no model — just a lookup table expressed as code.

This function was the entire triage brain of that support dashboard. When ticket volume was low and messages were predictable, it held up. Under real load, three failure modes surfaced:

1. Unknown phrasing — "my thingy stopped doing the thing" hits the else branch every time.
2. Context blindness — a follow-up message ("still broken after trying that") is treated as a brand-new ticket, not a continuation of the prior exchange.
3. Silent drift — when a new product feature launched, every ticket about it fell through until someone manually updated the if/elif chain.

Reactive agents are appropriate for deterministic, enumerable inputs — mapping HTTP status codes to messages, for instance. They fail the moment the input space is open-ended.

A deliberative agent maintains the full history of a conversation and asks a language model to reason over that history before responding. The model's context window becomes the agent's working memory — not a keyword index.

When I replaced the reactive triage widget with a deliberative loop, "my thingy stopped doing the thing" produced a sensible response on the first try. The model inferred intent from context rather than matching keywords. More importantly, follow-up messages — "still broken" or "never mind, found it" — landed correctly because the agent remembered what had already been said.

Here is the minimal deliberative version — the canonical first runnable block for this path:

The structural change from the reactive version is small but fundamental:

• Conversation history accumulates every turn, so follow-up messages carry full context.
• No if/elif chain — the model interprets intent from the message itself.
• claude-sonnet-4-6 applies its 200K-token context window to surface the most relevant response, including for phrasings that were never anticipated when the system was built.

After shipping the deliberative version, the next challenge was explainability. When a teammate asked "why did it suggest a password reset for that ticket?", there was no audit trail — just a response.

The ReAct pattern (Reason + Act) addresses this by asking the model to write out its reasoning before taking action. Each step has the shape: think about what to do, then do it. When I added explicit reasoning to the support agent, two things improved: debugging became possible (I could read the thought chain), and response quality went up (written reasoning caught errors before the final answer was delivered).

The reasoning chain becomes part of the context passed to the next step. Every subsequent decision the agent makes has visibility into why the previous step chose what it chose — not just what it chose. This is the first taste of the shared-context principle that module 06 formalizes.

Mid-Module Checkpoint

Before moving on, consider: what would happen if two separate deliberative agents worked on different halves of the same task — without sharing their conversation histories?

Each instance would make independent assumptions. Their outputs would likely conflict or duplicate work. This is the multi-agent failure mode that module 06 diagnoses and that the linear architecture in modules 02 through 05 is specifically designed to avoid. Keep that failure mode in mind as the path builds up.

The reactive and deliberative patterns establish the why. The architecture used throughout the rest of this path is a linear agent: a single model instance that receives a task spec, generates a step plan, and executes each step sequentially — with the full prior context visible at every turn.

No parallel agents. No fragmented histories. Each step builds on the one before it.

This is intentionally minimal. Module 02 adds the planning-and-execution loop. Module 03 registers tools the agent can call. Module 04 inserts human checkpoints. Module 05 assembles the full capstone. Every expansion is earned by the prose that introduces it.