Agentic Architectural Patterns

1An agent doesn't grade its own paper

First family: control, starting with who judges. Reread your essay at midnight: you read what you meant to write, not what is written. The book says the same of an agent. One that produces a solution and then judges it, like a human, "struggles to be an objective critic of its own work" (lesson 111). It finds excuses for its mistakes.

So the book separates the two roles. The pattern is called Hybrid Planner + Scorer. In the book's example, a planner agent writes three advertising slogans, then a scorer agent ranks them.

The scorer still has to judge on the right criterion. A generic metric such as BERTScore only measures how much two texts resemble each other. The book calls it "logic-blind". A plan that deletes the data before backing it up can thus get a good score (lesson 112). So you need a grid specific to the trade. You calibrate it on a golden dataset: a set of cases whose right answer you already know.

This pair runs in a loop, but not the one you would expect. The book calls it the Self-Improvement Flywheel, in four beats: generate, evaluate, learn, deploy. Evaluate is the key step, because "an agentic system can only improve what it can measure" (lesson 110).

Learn, here, does not mean fixing the text. It means retraining the planner, then the scorer, on the graded feedback. That is fine-tuning: resuming a model's training on chosen examples.

2An agent that learns from its grader ends up fooling it

In the previous idea, the planner and the scorer are retrained on what the other produces. The book calls this setup Coevolved Agent Training. It creates a risk: a pupil ends up guessing what pleases the marker, stops trying to do well, and learns the mark scheme.

The book's example shows this risk (lesson 115). The planner fixes code, and the scorer grades its fixes. The planner discovers a trick: wrapping the error in a try/except block. The block swallows the error: the program no longer crashes, but the bug is still there. The scorer, trained on standard metrics, applauds. The system stops improving.

The book names two failures of this setup (lesson 114):

• Collusion: the planner learns to "game" the system and produces mediocre outputs that the scorer lets through. The try/except above is one case.
• Runaway divergence: the system drifts away from what the business wants, to push up an internal number the loop measures.

To cut both failures, the book prescribes external anchoring: a reference point the loop never retrains, like an exam marked by an outsider whose mark scheme the pupil does not know. Without "periodic human review or validation against a golden dataset", the loop risks these failures (lesson 114).

To get out of the dead end in the example, the book retrains the scorer on pairs of "patch" versus "real fix". The old tricks stop paying, and the planner has to learn to debug.

3Two opinions beat one, if they are independent

A lone scorer can be wrong, or be fooled. So the book also proposes crossing several opinions. Before a major operation, you ask for a second medical opinion. It only helps if the two doctors don't come from the same school.

The book has two patterns on this model. Both go through an orchestrator: the coordinating agent that hands out the work and gathers the results. The two patterns differ in the number of agents:

• Parallel Execution Consensus: two independent agents get the same task, for example a credit score. Model A returns 720, B returns 725. The gap fits within the 10-point tolerance, so the orchestrator validates the average, 722.5. With 720 and 780, a human decides.
• Majority Voting: three agents or more vote. Two "approve" out of three, and the file goes through.

To keep these opinions independent, the book sets three conditions:

• an odd number of agents, "to prevent ties";
• agents "ideally... powered by different foundation models", that is, large language models from different vendors;
• a planned path for disagreement.

This setup has a price, and the book owns it: it is "the most expensive redundancy pattern" (lesson 75).

4When an agent fails: rephrase, save, call the human last

Second family: the frame around the agents, starting with failure. Control catches a bad answer, but an agent can also fail outright. A key won't turn in the lock: forcing it is pointless. You pull it out and change the angle.

The book applies this rule to agents with four complementary patterns. The first one touches the prompt, the instruction sent to the model:

• Adaptive Retry with Prompt Mutation: when the failure repeats identically, "simply resending the same request is futile" (lesson 72). So you rephrase the prompt. Example: invalid JSON is retried with "think step by step, then format as JSON".
• Watchdog Timeout Supervisor: a timer wraps the call to the model. Past 10 seconds, it cancels the call and hands over to a simpler fallback agent.
• Incremental Checkpointing: each finished step is saved. If the summary service goes down, the rerun therefore resumes at the third step.
• Delayed Escalation Strategy: the human arrives last, with a complete file. Example: the agent is 85% confident against a 95% threshold. It retries twice, then the file goes to a human.

Of the four, saving is the easiest to show. Here is an imagined pseudo-code, not from the book. Before each step, the script checks whether it is already saved:

for step in ["clean", "entities", "summarize"]:
    if exists(save, step):
        state = load(save, step)
    else:
        state = run(step, state)
        write(save, step, state)

The book then chains these patterns on a loan request (lesson 68). The chain follows this order: retry, automatic agent restart, fallback model, then escalation to a human. Each step is written to a log.

To judge these defenses, the book prescribes one metric per pattern, such as the recovery rate for retry. The table in the same lesson lists eight. The reason: "In a production-grade system, robustness cannot be a matter of opinion".

5One agent coordinates, the others execute, and code decides what's next

After one agent's failure, the next task is to organize the work of several. On a building site, the foreman decides who comes when. The mason lays the bricks, the electrician pulls the cables. If the foreman does everything himself, the site stops with him.

The book draws the Supervisor pattern from this. A central orchestrator breaks the work down and hands it to sub-agents, specialized agents. Then it decides what comes next.

This pattern comes with two rules:

• Do not build a God agent, an agent that does everything: it coordinates and it executes. The orchestrator only coordinates: it stays "solely responsible for coordination" (lesson 45). The work itself goes to the subagents.
• Start centralized: a single orchestrator at the center, which hands out the tasks and receives all the results. The book sees "a good starting point" in it (lesson 46).

The book illustrates this pattern with a loan request. An orchestrator agent chains three specialists: document verification, credit check, risk assessment. Under a score of 600, it rejects the file early.

Between these agents, no free prose. The book calls natural-language handoffs "a recipe for instability" (lesson 45). So it imposes strict output schemas: a response format fixed in advance, for example JSON with imposed fields.

The book is also wary of long chains: one agent hands a task to a second agent, which hands it to a third. Each link adds a full round trip with the model, so time and cost add up. Hence this warning: "be cautious with deep delegation chains" (lesson 137).

What remains is writing the sequence of steps, and the book wants it in code. Lessons 147 and 148 compare two agent-programming tools on the same case:

• CrewAI organizes agents into a team of roles. There, the intermediate agents "continued to operate despite the initial validation error" (lesson 148).
• LangGraph describes the flow as a graph of steps that read a shared state. A branch tested in code, called a conditional edge, looks at an error key. As soon as a field is missing, it sends the file to rejection.

6An agent's rights are set in code, not in the prompt

Coordinating the agents is not enough: you also have to bound what each one may do. An intern prepares a transfer, but doesn't hold the bank's key.

The book applies this rule to an agent that drafts a suspicious-activity report (lesson 152). The agent gets the draft_report tool to write, not the submit_report tool to send. The workflow, the chain of steps, then waits for the green light of a human, the compliance officer. Code bounds the agent here: the sending tool is never given to it.

The prompt, the text of instructions given to the model, bounds nothing on the other hand, and the book admits it. The example in lesson 131 puts numeric success criteria in the prompt. It adds a verification loop to repeat three times. The book warns: "N=3 is not a Python parameter" (lesson 131). In other words, nothing in the code counts the three passes.

The book calls these instructions semantic guardrails: rules given to the model, which nothing in the code enforces. In production, it recommends evaluation tests outside the prompt, written with tools such as DeepEval or Ragas.

7A spending cap cuts the agent off before the bill

Bounding an agent's rights doesn't bound its spending. A mobile plan that cuts off at 100% spares you the 900-euro bill. The book applies this idea to agents under the name tokenomics.

This tokenomics counts in tokens. A token is a piece of a word: the unit the model counts and bills. Tokens become an internal currency here, with a quota per agent. The stakes are real: a learning loop can consume "10×–100×" the tokens of standard use of the model (lesson 117). The book doesn't source that figure.

The book's example shows the cap at work. An analyst agent finds 5,000 PDFs to summarize and gets a 50-dollar budget. Around the 50th PDF, 45 dollars out of 50 are already spent, which is 90% of the budget. A circuit breaker, like the one in an electrical panel, then cuts the collection and forces the report step with what the agent already has.

A minimal circuit breaker is a simple test in the script that launches the agent:

# imagined pseudo-code
if spent >= 0.9 * job_budget:
    stop_collection()
    produce_report(current_data)

8Choose the patterns before the code, grow only when needed

One question remains: where to start, faced with about fifty patterns? The book answers with a method, pattern-first: patterns come first. You draw the plan before raising the walls. Likewise, you choose the patterns before the framework, the code library that runs the agents.

For the book, "Patterns generate architectures" (lesson 155). The framework is only an accelerator (lesson 153). The book immediately adds a brake: "Implementing every pattern at once is not only impractical but often unnecessary" (lesson 121).

So you start small, with a monolithic application: a single program, launched as one block. The orchestrator calls its specialists one after the other. It keeps its guardrails: a maximum delay, an escalation to a human.

This small application grows in stages. You move to separate services, small independent programs that talk to each other, when "driven by necessity" (lesson 122). The course frames it as two questions to ask: do you need more than three or four specialized agents, or long processing that runs in the background (lesson 125)?