Agent Feedback Loops and Parallel Agents: Two Books Read

Table of contents (6 sections)

I write reading notes on technical books. To check them, I have agents proofread them. An agent is one Claude instance, an AI working alone on a task with its tools. Each reviewer compares my claims to the book.

One day, these reviewers flagged perfectly real facts as invented. The fault was mine: I had handed them condensed notes instead of the text of the book. They could not confirm what they could not see. A judge is only worth what it can see.

Picture a student grading their own paper. They recognize their own ideas, find them clear, and give themselves a good mark. An outside grader sees what the student no longer can. (This image is mine, it does not come from the books.)

With agents, this becomes a feedback loop. In the loop, one agent writes, another scores, then you fix and go again. You stop when the score reaches a threshold: below the threshold you fix, above it you exit.

I run this every day. I also launch several agents at the same time, which means in parallel, instead of having them work one after the other. An agent can launch others, called subagents. Each has its own context window, the text it keeps in view. Only its final message comes back to the one that started it.

I had read four books on Claude Code. The best one, The Claude Code Operating Model, puts numbers behind its own claims. I wanted something more advanced on these two topics. Packt gave me access to its ExpertEdge subscription platform, and I read two 2026 books there:

• Agentic Architectural Patterns for Building Multi-Agent Systems, by Ali Arsanjani and Juan Pablo Bustos. I call it "Arsanjani."
• Spec-Driven Development with BMAD, by Marlon Vidal Ferreira. I call it "BMAD," after the name of the tool it teaches.

Both taught me something about loops. On parallelism, they describe more than they measure.

The one who writes must not be the one who scores

This is the strongest idea in either book, and it comes from Arsanjani. An agent that produces a solution and then judges it "struggles to be an objective critic of its own work" (lesson 111). It rationalizes its mistakes: it finds good reasons to leave them as they are.

I have written about this before: No Agent Grades Its Own Homework. The book turns it into a pattern, a design recipe that comes up often. It is called Hybrid Planner + Scorer. One agent plans (the planner), another scores (the scorer), and the score is used to adjust the first.

The book adds that the loop is only as good as its measurement: a system of agents "can only improve what it can measure" (lesson 110).

Arsanjani also names two failure modes. They happen when the judge evolves alongside the agent that produces the output (the generator). This is the vocabulary that helped me most:

• Collusion: the generator learns to "game" the system. It produces mediocre output that the judge lets through (lesson 114). To picture it: the student who studies the grader's tastes instead of the subject.
• Runaway divergence: the system drifts away from the real goal to optimize an internal metric, a number it tracks itself (lesson 114).

His example is about code (lesson 115). A fixer agent patches a vulnerability. An auditor agent scores the patch. The story unfolds in two cycles:

1. In the first cycle, the fixer finds that wrapping a crash in a try/except is enough for a good score. A try/except catches the error and hides it. The system plateaus.
2. In the second cycle, the auditor is retrained on pairs of "band-aid" versus "real fix." Retraining a model means making it learn again from new examples. The fixer's scores drop, and it has to learn to actually debug.

A judge like this is called an LLM judge: a language model, an AI that writes text, asked to score another model's output. If its criteria are generic, it can be fooled. A text-similarity metric is a calculation that scores how much two texts look alike. The book says one of them, BERTScore, is "logic-blind" (lesson 112).

Mind the difference in nature with my loop. Arsanjani's retrains models (lessons 113 to 115). Mine fixes a document based on a report, without touching any model. What carries over is the failure and the remedy, not the mechanics. The numeric thresholds and the maximum number of rounds described below are mine alone.

Against cheating: an outside check, then a limited budget

Against collusion and divergence, Arsanjani prescribes an external anchor: "periodic human review or validation against a golden dataset" (lesson 114). An external anchor is a checkpoint placed outside the loop, one the agents do not control. A golden dataset is a set of cases whose right answer is known in advance.

For coding agents, the most direct anchor is a test that actually runs. A test is a small program that checks that a feature works. This is where the BMAD book is useful.

BMAD is an open source working framework. Role-based agents (analyst, architect, developer, tester) pass written documents to each other before any code exists. The book yields six control moves that I keep, whatever the tool:

• Red before green. A red test fails because the feature does not exist yet. A green test passes. A test module generates, before the code, one test per acceptance criterion, a written condition the feature must meet. Each test is marked test.skip(). The method is called ATDD, for Acceptance Test-Driven Development: you first write the tests that check that the feature does what was asked. The developer removes the skip markers one by one, from red to green. Tests written after the implementation do not necessarily cover every scenario, the book says (lesson 26).
• A gate before writing code. A gate is a check you pass before moving on. The implementation readiness check cross-references the requirements, the architecture and the work breakdown. It returns PASS, CONCERNS or FAIL (lesson 15). A FAIL is nothing to dread: the mistake still lives in a document, not in code.
• A three-pass review after each story. A story is a unit of work written in a file, small enough to fit in one session. A session is a conversation with the agent. The three passes: a logic-error hunter, an edge-case hunter and an acceptance-criteria auditor. An edge case is a rare situation, like an empty list or concurrent access. The book recommends giving it to "ideally a different model" (lesson 30) and states that the review layer "is not a formality" (lesson 18).
• A self-correction loop. In the demo, an end-to-end test fails: it walks through the application the way a user would. The workflow then fixes itself. A workflow is a BMAD procedure started by a command. It reruns the test suite, finds another defect, fixes it and verifies (lesson 30).
• A fresh session per step. The book forbids chaining ("never chain," lesson 43), because accumulated context biases what follows. Opening a fresh session means starting without any memory of the previous one.
• A retrospective that rewrites the instructions. An epic is a large batch of stories. At the end of an epic, after a test coverage gate, the retrospective rereads the notes each story left behind. It regenerates project-context.md (lesson 31). This is BMAD's equivalent of a CLAUDE.md, the instructions file the agent rereads at the start of each session. It becomes "the living record of how the project has learned to build itself" (lesson 19).

One last guardrail, from Arsanjani: the budget cap. A cap is a limit you do not exceed. In the book's example, an analyst agent must summarize 5,000 PDFs on a $50 budget. At 90% of the budget spent, around the 50th PDF, a circuit breaker stops collection. A circuit breaker cuts everything when a limit is crossed, like the one in a house. The agent then switches to the report using the data already collected (lesson 117).

The same book admits that a learning loop can cost "10 to 100 times" a normal inference, without citing any source. An inference is a call to the model to get an answer.

On the BMAD side, the cost boils down to "time- and token-intensive" (lesson 31) and "very expensive in terms of token usage, but much less than letting these problems reach production" (lesson 29), with no figure in tokens or dollars. A token is the small chunk of text the model reads and your subscription counts. So for a multi-round loop, set the cap before the first round, not after the first bill.

My own loop: a score to reach, three rounds at most

Neither book gives an exit threshold, a number of rounds or a split of roles for a review loop. Here is mine, worked out on four book notes and one article. A book note is my reading note on a book, published on this site. The notes from the previous series went from 59 to 76 out of 100 on the first round and ended between 84 and 97 after the Sonnet rounds. The article from the previous series went from 6.1 to 8.1 out of 10.

A round is one full cycle: a reviewer scores, then another agent fixes. Sonnet and Opus are two Anthropic models, Opus being the more expensive: I keep it for the last pass. Each role receives and returns this:

The exit thresholds depend on what I review:

• For a book note: at least 85 out of 100, a factual fidelity score of at least 20, and every idea at 8 minimum on four axes.
• For an article: an average of at least 8 out of 10 and no criterion below 7.

My cap is three Sonnet rounds at most: three tries, then stop. Beyond that, I move to the Opus review with the list of what blocks, rather than keep looping.

The reviewer of a new round receives the previous round's report. It keeps the same grid and the same severity this way, because a fresh reviewer with no history scores differently.

On isolation, the reviewer receives the text, the rules, the book and the previous report (see the table), without the reasoning behind the writing. Each report goes into a file. Each corrected version is committed between rounds, meaning saved in the code history. So a session that restarts loses the running agents, not the work. The report skeleton I ask for looks like this:

Moyenne : X/10 (seuil 8, aucun critère < 7). Sortie atteinte : oui/non.

Critères notés sur 10 : accroche, structure, fidélité et faits, voix, autonomie, utilité, SEO, niveau par rapport aux étalons.

Pour chaque point perdu : le passage fautif cité, la source qui le contredit
(chercher par recherche de texte dans le livre, pas dans les notes), la correction demandée.
Pour passer le seuil : les corrections par ordre de priorité.

(That is the real template, in French, since my notes are in French. In English: average out of 10 with the threshold and the exit flag; criteria scored out of 10; for each lost point, the faulty passage quoted, the source that contradicts it found by text search in the book rather than in the notes, and the fix requested; then the fixes in priority order.)

Several agents at once: described in the books, never measured

One question remains: does running several agents in parallel really improve the result? The books describe it, but never measure it.

A comparison: handing three chapters to three people who write at the same time. You need a lead who hands out the work, then someone who gathers the chapters. With agents, it is the same pattern.

Arsanjani describes parallelism. Multi-agent means several agents cooperating. It is presented as coordination that "allows for parallel processing" (lesson 43). The book shows real concurrent code, in two versions:

• A supervisor, the agent that hands out the work, launches three data collectors in threads before a writer assembles the report (lesson 50). A thread is a line of execution: a job that moves forward at the same time as the others.
• Another supervisor launches them with asyncio.gather (lesson 91). It is the Python function that starts several tasks together and waits for them all to finish.

Two patterns are built to check a result:

• Consensus through parallel execution (lesson 69): two independent agents do the same task, and their scores are compared with a 10-point tolerance.
• Majority voting (lesson 75): three or more agents answer, and the most frequent answer wins.

Merging the answers is covered, by averaging or voting, with escalation to a human on disagreement: you hand the case to a person.

Simultaneous writes to shared state have their own pattern (lesson 64). Shared state is a set of data that several agents read and change. Two agents writing at the same time can overwrite each other. The book proposes atomic operations on a store such as Redis, a fast in-memory database. An atomic operation cannot be cut in two by another one. It also provides a time to live for the information.

The limits are elsewhere:

• In the verification examples, the code calls the agents one after the other, and their answers are made up. The score in lesson 69 comes from random.randint, a function that draws a random number. The votes in lesson 75 are hardcoded.
• The cost of redundancy is stated in one sentence, "the most expensive redundancy pattern" (lesson 75), not measured.
• There is nothing about coding agents editing the same repository: no file conflicts, no isolated branches. A repository is the folder where a project's code lives.

The advice that helped me is about independence. A second medical opinion is only worth something if the second doctor did not come out of the same school as the first. The book says this about agents: they should be "ideally powered by different foundation models" (lesson 75). A foundation model is the large starting AI model, like Claude. You need an odd number of agents to avoid ties, with a planned path for disagreement. Three copies of the same prompt means paying three times for the same mistake. A prompt is the instruction given to the agent.

BMAD says less, and the book does not agree with itself:

• Lesson 31 describes a review that spawns three agents in parallel. Lesson 18 states that the same review runs three passes in sequence.
• Lesson 42 answers "can I run several stories in parallel?" with yes, under conditions. You have to customize the workflow to split by layer rather than by vertical slice, or hand independent epics to different owners. That advice describes a team of people, not agents.
• Party Mode loads all the agents into one discussion to get several viewpoints (lesson 7): a single conversation thread.
• BMAD Loop is a community-built orchestrator, a program that launches the steps in order. It chains workflows in sequence (lesson 31).

So neither book says how many agents to run at once, what it costs, or how they cope on a real repository.

Here is what I do, without claiming it is the right answer. The reviews of several book notes run in parallel, two or three agents at a time on my server (a comfort figure, not a measurement). Each writes its report to a file, and I commit between rounds. This matches what Arsanjani's book calls incremental checkpointing: saving every step so an interrupted batch restarts from the files already written. The comparison is mine, the book does not apply it to coding agents.

Which book to read, depending on your profile

Agentic Architectural Patterns (Arsanjani and Bustos): 5.6 out of 10 on my reading note, provisional score. It is a catalog of about fifty patterns that names failures well and measures nothing: not a benchmark, unsourced gains, code that simulates the model.

Its first sections are enterprise context tinted with Google Cloud, to skim: model selection, RAG (making the agent search documents) and fine-tuning (retraining the model). Read it if you already run agents and are looking for words for your loop failures, starting with lessons 110 to 112, 114 and 115.

If you have never written an agent, start with AI Engineering by Chip Huyen (the reading note), stronger on the foundations and on measuring quality. Between Huyen and Arsanjani, Huyen first: Arsanjani comes after, as targeted reading.

Spec-Driven Development with BMAD (Ferreira): 5.2 out of 10 on my reading note, provisional score. It is a short 3 h 20 course, a tool manual, dated (the author warns that his course "may contain outdated info," lesson 6). It is tied to Cursor, the AI code editor he is an ambassador for in Brazil.

Read it for its control loops (red tests, gate, review, retrospective) and its fresh-session rule, skim the rest. It suits a small team better than someone coding alone, and the book says so itself ("a team process, not a solo tool," lesson 45).

Conclusion

I went looking for books that would teach me to make agents work together. What helped most concerns what each agent is not allowed to believe about the other: the judge that applauds a try/except, the reviewer that reads notes instead of the text. Arsanjani describes cooperation with code that simulates the agents, and BMAD with tool demos. Neither says what happens with ten real agents on a repository.

So, more advanced than what I practice? On the vocabulary of loop failures, yes: collusion, divergence and external anchoring helped me. On the mechanics of a review loop and on coding agents in parallel, no. Neither fixes an exit threshold or a cap on rounds for a review loop. Neither gives a number of agents to run at once. My loop already does all that.

I have not found a book that puts numbers on parallelism. The figure from my server, two or three agents, is a comfort setting, not a measurement, and I would like to read someone who has one.