Choosing the Architecture Pattern

In the previous lesson, we took Atlas Financial’s vague mandate and decomposed it into four scoped tasks, document intake, policy checking, memo drafting, and the final decision (which we keep human). Each of those tasks now needs an architecture. This lesson gives you the framework for choosing between the three architectural patterns, workflow, agentic, and augmented LLM, and for defending the choice.

This is the highest-leverage decision an architect makes. Choose an agent where a workflow would do, and you have built something expensive, slow, and hard to debug for no benefit. Choose a workflow where the task genuinely needs runtime adaptation, and you have built something that breaks the moment reality deviates from your flowchart. In this lesson, we will cover:

• The three patterns as a spectrum of increasing autonomy, cost, and unpredictability

• The augmented LLM as the baseline building block you reach for first

• A decision framework for choosing a pattern for any scoped task

• Why “use an agent” is the exam’s favorite over-engineering distractor

The three patterns are a spectrum of autonomy

There are three architectural patterns, but they are not three unrelated options. They form a spectrum. As you move along it, you hand more control to the model, gaining flexibility but giving up predictability, and paying more in latency and tokens for each step.

Here is the governing principle, and the single most important idea in this lesson.

This is the inverse of how most engineers instinctively approach LLM design. The exciting word is “agent,” so people start there and work backward. The architect starts at the bottom and moves up only under pressure.

The augmented LLM as the baseline building block

The augmented LLM is a single language model call enhanced with some combination of three things. Retrieval lets it pull in relevant context, tools let it call functions to read or act on the world, and memory lets it carry state. It is not a loop and not a multi-step plan. It is one bounded interaction, context goes in, and a structured result comes out.

This is the building block the other two patterns are made of. A workflow is a series of augmented-LLM calls on a fixed path. An agent is an augmented LLM called repeatedly in a loop where the model chooses what happens next. So the augmented LLM is not the “beginner” option. It is the atom, and a large fraction of real production tasks need nothing more than one well-designed augmented-LLM call.

Take Atlas’s document intake, where the system reads an uploaded financial statement and extracts the line items into structured JSON. This is exactly right for an augmented LLM. There is one input, one output, no branching, and no need for the model to decide anything about control flow. An augmented LLM with a document in context and a structured-output schema does the whole job. Reaching for a workflow or an agent here would add moving parts that buy nothing.

Workflows are predefined paths of steps

A workflow chains multiple LLM calls along a path the developer defines in advance. The model does the work at each step, and the code decides which step runs next. Common workflow shapes include the following.

• Prompt chaining: The output of one call feeds the next (extract, then validate, then summarize).

• Routing: An initial call classifies the input, then directs it to one of several specialized downstream paths.

• Parallelization: The same input is processed several ways at once and the results are combined, for example running three independent checks and aggregating them.

The defining property is simple. You could draw the complete flowchart before running anything. The branches are known. Routing is still a workflow, because the set of routes is fixed in advance. The model picks among known options, it does not invent new ones.

For Atlas’s policy checking, a workflow fits. The steps are stable for every application. First, pull the relevant policy sections for this loan type. Second, check the application’s figures against each rule. Third, produce a structured list of pass, fail, and flag results. The path does not change based on what is found, because a failed rule is recorded, not a trigger to improvise a new investigation. That is a workflow, and building it as an agent would trade away the auditability a bank needs (a fixed path produces the same reasoning trace every time) for a flexibility the task never uses.

Agents let the model control the flow

In an agentic architecture, the model runs in a loop and decides the next step at runtime based on what it has found so far. There is no predefined path. The agent chooses which tool to call, reads the result, and decides what to do next, continuing until it judges the task complete (a judgment the application must still bound and verify, as Foundations-level loop-termination discipline requires). Agents are the right call when the path genuinely cannot be known in advance.

• The next step depends on intermediate results in a way you cannot enumerate. In “investigate why this application was flagged,” where you look depends on what you find.

• The task is open-ended, such as research, debugging, or multi-step problem-solving with unknown structure.

• Which tools to call, and in what order, is context-dependent rather than fixed.

Notice that none of Atlas’s four tasks are truly agentic. Intake is a single transformation. Policy checking and drafting are fixed paths. The final decision is kept human. This is realistic and worth internalizing. Many production systems that get called “AI agents” are, correctly designed, workflows and augmented LLMs. An agent would be right for Atlas only if it added, say, an open-ended “investigate this borderline application” capability where a loan officer wants the system to autonomously chase down whatever is anomalous, a genuinely unknown path.

The decision framework

For any single scoped task, ask these questions in order and stop at the first “yes.”

1. Can this be one bounded call? If the task is a single transformation, input to output with no control-flow decisions, use an augmented LLM (with retrieval, tools, and memory as needed). Stop.

2. Can you draw the complete flowchart in advance? If the steps and branches are all known before running, use a workflow (chaining, routing, or parallelization). Stop.

3. Does the path genuinely depend on runtime results in ways you cannot enumerate? Only then use an agent, and bound its loop, tools, and stopping condition in code.

Two cross-checks the exam rewards:

• Cost and latency: Each step up the spectrum multiplies calls and tokens. If two patterns both work, the cheaper, more predictable one wins unless the task’s value justifies the extra autonomy.

• Auditability and reliability: Regulated and high-stakes contexts (like Atlas) favor lower-autonomy patterns because a fixed path produces a consistent, reviewable trace. Autonomy is a liability where every decision must be explained to an auditor.

The cost difference is not abstract. A single augmented-LLM call for Atlas’s intake might make one model call per document, so a batch of a thousand statements costs and latencies such as a thousand calls. A workflow for policy checking, with three chained steps, costs roughly three times that per application, because each step is its own call, even though every step is cheap and fast individually.

An agentic investigator, deciding at runtime whether to pull a credit bureau report, re-check a ratio, or ask a follow-up question, might make anywhere from three to fifteen calls depending on what it finds, and that variance is itself a cost you have to plan for, since you cannot quote a single latency number to the business the way you can for the other two patterns. This is exactly why the decision framework insists on stopping at the first “yes.” Every extra step up the spectrum is a cost and a predictability trade the business has to actually want, not one you default into because the word “agent” sounds more capable.

Anti-patterns

These are the wrong-but-tempting moves the exam uses as distractors.

• Agent-first design: Starting from “let’s build an agent” and fitting the problem to it. The exam consistently rewards the least autonomous pattern that satisfies the task.

• Mistaking routing for agency: Because a routing step uses the model to choose a path, people call it an agent. It is a workflow, because the routes are fixed and known.

• Over-decomposing a single call into a workflow: Splitting one bounded transformation into three chained calls adds latency and failure points without benefit. If one augmented-LLM call does it, use one.

• Ignoring the auditability cost of autonomy: Choosing an agent in a regulated context because it is flexible, without accounting for the fact that a non-deterministic path is far harder to explain to a regulator.

• Confusing “the whole system” with “one pattern”: A real system (like Atlas) is usually a composition, with augmented LLMs for some tasks, workflows for others, and maybe one agent for a genuinely open-ended part. The pattern is chosen per task, not once for the whole system.

Exercise: Choose the pattern

Each scenario tests whether you can place a task correctly on the autonomy spectrum. Choose the best answer.

What’s next?

We’ve placed each of Atlas’s tasks on the autonomy spectrum. Next, we go deeper into the highest-autonomy end and ask when a single agent should instead become a multi-agent system with a coordinator and specialists, when that added structure earns its cost, and what provenance and scope discipline it requires to stay reliable.