38 Managing Multiple AI Agents
This chapter is part of a book in active development and has not yet been through the author’s review. Content may change as the review advances.
The research decision. Running several AI agents means running several loops at once. You decide how to split the work into scoped jobs, in what order those loops run so that no early mistake slips downstream, and which step in the chain no loop is ever allowed to close.
38.1 Why this decision matters
The decision on the table: how many AI loops you set running on one piece of your work, in what order, and which step you keep out of every one of them.
“Bring me a draft, not a pile of AI output. I want to know which part each tool touched, what you told it to do, and how you checked it. If you cannot tell me that, you did not write it.” — your thesis advisor, reading the draft you are about to defend
By now one AI assistant can draft, cite, critique, and polish in a single breath. The temptation is to open four of them at once and feel four times as safe. You are not. Four roles reading the same draft with the same instructions tend to miss the same thing and agree loudly about it. And each of those roles is not one prompt. It is a loop, running until you or it decides to stop. Four loops going at once is four times the output and, unmanaged, four times the unsupervised work. The advisor above does not want a louder chorus. She wants to see that you broke the job into pieces, put those pieces in a sane order, and stayed the one person who decided what the draft claims. This chapter gives you that management skill.
38.2 The concept
Start with the unit you are actually managing. The AI loop is the cycle you have been running since the beginning of this book: you prompt, you read the output, you interrogate it, you refine the ask, you run it again. One loop, one job, one person watching. Agentic tools are AI systems that run that loop on their own, deciding their own next step and calling their own tools between your turns (Yao et al. 2023). Example: you ask for the citations to be checked and the tool searches, reads, rechecks, and revises across several turns before it comes back to you. It is faster, and every turn you did not read is a turn you did not supervise.
So the real management question is not how many prompts you write. It is how many loops you have running, what each one is allowed to touch, and where they hand off to each other. You orchestrate loops, not prompts.
The move that turns a crowd of loops into a workflow you can defend is task decomposition: breaking one large job into smaller subtasks, each with a single clear owner (Malone and Crowston 1994). Example: instead of asking a tool to “improve my draft,” you split the work into check the design, check the citations, and tighten the prose. Each piece now has a pass-or-fail you can judge.
Each piece becomes a scoped role: an AI job narrow enough to state in one sentence and check in one pass. Example: “flag every sentence in my results section that claims more than my sample can support.” A scoped role has a clear finish line. “Make it better” does not. That finish line is what makes the role’s loop safe to run: the loop stops when the job is done, and you can tell from the outside whether it is.
The backbone that keeps roles honest is the worker-critic pair: one role produces something and a second, separate role attacks what the first produced. Example: a worker drafts your limitations paragraph, then a critic hunts for the limitation the worker left out. A worker alone is confident about its own quality, which is exactly the blind spot it cannot see from the inside.
Wiring the roles means deciding what waits on what. A dependency is a required order between two subtasks, where one needs the other’s output before it can start. Example: a critic cannot attack a draft the worker has not written yet. Roles with no dependency between them run at the same time. Roles joined by one run in order.
The chain of dependencies you cannot shorten is the critical path: the longest run of must-follow-must steps in your workflow (Kelley 1961). Example: worker drafts, then critic attacks, then you integrate is three steps that cannot collapse into fewer. That chain sets the minimum number of rounds your workflow takes. Reading the critical path off your own design, instead of guessing it, is the skill this chapter drills. Count it in loops, not in messages. A single role may take four turns of prompting to finish its one job, and it still occupies one node on the path.
38.3 A worked example
You are finishing the write-up of a small health study: whether a ten-minute post-lunch walk is associated with a lower afternoon resting heart rate among the residents on your dorm floor. You have a draft and four AI roles waiting.
Split. You break the review into scoped roles. A clarity reviewer checks whether each sentence reads plainly. A methodologist checks whether “associated with” is the honest word for what your data can show. A citation-checker confirms the two heart-rate studies you cite are real and say what you claim. An editor tightens the prose. Each role owns one sentence-long job.
Wire. The worker drafts your limitations paragraph. The three critics can all read that draft at the same moment, because none needs another’s output. That is three loops running in parallel. Each one takes as many turns as it needs: the citation-checker probably runs four or five, searching, failing to find one of your studies, and coming back to tell you so. Then you integrate their notes, and the editor tightens what survives. Trace the arrows: worker to a critic is one, critic to you is two, you to editor is three. Your critical path is three arrows deep, and it runs three loops at its widest.
Keep one step human. The integrate step is yours, and it is the one node with no loop attached to it. When the methodologist says your walk-and-heart-rate result is only an association and the clarity reviewer loved the sentence that called it an effect, no role settles that clash. You do. The decision about what the write-up claims never enters the workflow as a delegated task.
The tools drafted, flagged, and polished. You split the job, set the order, decided when each loop had run long enough, and owned the claim that carries your name.
The dependency chain that sets the earliest possible finish, and which steps have slack, is the critical path in its original sense (Kelley 1961).
The block below counts the turns and finds the critical path, which is the only thing worth optimizing. The integration node stays human, and it does not appear in this table.
import numpy as np, pandas as pd
SEED = 464
rng = np.random.default_rng(SEED)
# Turns each role actually needs. The three critics do not wait on each other.
roles = {"worker: draft limitations": 3, "clarity reviewer": 2,
"methodologist": 3, "citation-checker": 5, "editor: merge": 2}
turns = {r: int(rng.integers(max(1, n - 1), n + 2)) for r, n in roles.items()}
worker = turns["worker: draft limitations"]
critics = {r: t for r, t in turns.items() if "review" in r or r in
("methodologist", "citation-checker")}
merge = turns["editor: merge"]
serial = sum(turns.values())
parallel = worker + max(critics.values()) + merge
print(pd.Series(turns, name="turns").to_string())
print(f"\nall five in sequence : {serial} turns")
print(f"three critics in parallel : {parallel} turns")
print(f"critical path : worker -> {max(critics, key=critics.get)}"
f" -> editor")
print("\nthe slowest critic sets the schedule, so speeding up the other two")
print("buys nothing. and the integration node is yours, not the editor's")38.4 An AI failure case
You ask a tool to design your multi-agent workflow, and it returns a confident, well-formatted plan: run the worker, the methodologist, the skeptic, and the editor all in parallel to “save rounds.” The plan runs in your head without a hitch. Here is the trap. The editor and the skeptic have nothing to read yet, because the worker has not drafted anything. The tool scheduled three roles to start before the input they depend on exists, and dressed it up as efficiency. Hand that plan to an agentic tool that executes it for you and the failure gets quieter, not louder: three loops run on an empty draft and return three confident reviews of nothing.
You catch it by drawing the arrows and asking one question at each role: does this role’s input exist at the moment it starts? The editor’s input is the integrated draft, which does not exist until the end, so “editor in parallel with worker” is impossible. Redrawn honestly, the plan is a critical path three arrows deep, not one. A green, tidy plan is not a valid one. You check the dependencies, not the confidence.
38.5 It is your turn
You are working inside Studio 12: Special topic: agentic AI, release, and the next cycle. Keep what you write here; the studio’s milestone chapter is where it joins the other lessons’ pieces into one artifact you can defend.
Your project already has a research note and a reusable capsule. This step sets up the small AI team that runs your closing review — the studio’s core practice. First state who chooses each next step: you, a fixed script, or an agent that plans and calls tools; never call a manually sequenced chat autonomous. One well-run assistant playing the roles in turn is a legal team; the wiring discipline is the same, and none of it hands over your judgment.
The hands-on half of this section lives in the chapter’s companion notebook: open it in Colab with the badge at the top, and work the steps there.
Commit your own answer first, then delegate. Each prompt below opens a loop you supervise, and one of them is a loop about your other loops. Read what comes back, push on the weak part, run it again. Each prompt is a checkable job, not a request for a verdict.
The split and the order can be informed by a tool, but three calls stay yours alone. You decide which jobs are worth their own loop and which just multiply output you cannot supervise. You decide the order, so that no role settles a question a role upstream of it should have answered first. And you keep the integrate step human: when two roles disagree about what your draft claims, you make that call in your own words. A workflow that hands the claim to a tool is not a workflow you can defend. The rule scales with the number of loops rather than bending to it. More agents does not mean looser command; it means the same command discipline, repeated.
Pick one real section of your project to revise: your methods, your results, or your limitations. Everything below applies to that section only.
Set up three loops, each with a one-sentence job you could grade. A writer that drafts or rewrites. A skeptic that attacks what the writer produced and looks for the claim reaching past your evidence. An auditor that checks your numbers, your citations, and whether each sentence matches an output you actually have.
Decompose, then hand back the human step.
I am splitting the review of my health write-up into scoped AI roles. Here are my section headings and one line on each: [paste them]. Propose a table with one row per role: the role's one-sentence scoped task, the draft or input it needs, whether it can run in parallel or must wait on another role, and the single decision it must hand back to me.After running, verify: check that every “hand back to me” cell names a real never-delegate decision, not one invented to look cautious. Counters illusion of completeness (a tidy role table that reads thorough while omitting the check that matters).
Wire them, and declare each role’s capability while you do: who executes it, who chooses its next step (you, a script, or the tool), what tools it may touch, and what receipt it leaves. A role you sequence by hand is a workflow, never an autonomous agent. Write down which loops can run at the same time and which must wait for another’s output, then trace the longest chain of must-follow steps. That chain is the minimum number of rounds your revision will take.
Confirm the wiring has no early error slipping past.
Here is my proposed workflow as a list of "role A feeds role B" arrows: [paste them]. For each role, tell me exactly what input it depends on, and name any role I have scheduled to start before the input it needs actually exists.After running, verify: draw the arrows yourself and trace whether each role’s input exists when it starts. Counters plausible-but-wrong-method (a confident wiring that lets a role run before its input is ready).
Name the one node you keep human, the step where the loops’ work becomes your claim, and write down why no role is allowed to take it.
Run the round. For each loop, record how many turns it took, what you rejected, and what you kept. A loop whose output you accepted without reading is a loop you did not manage.
Red-team the decomposition.
Act as a hostile reviewer of my AI workflow, not of my draft. Name every place an early mistake in one role could flow downstream unchecked, and every role whose job overlaps another so much that it adds no independent check. Do not rewrite my plan.After running, verify: if it only praises your plan, push back and demand the single worst wiring flaw. Counters sycophantic agreement (praise that reviews your ego, not your workflow).
Log every loop in your AI Research Ledger, and verify at least one output with a named method from the Verification Guide. An AI reviewer may run the check with you; the decision to accept or reject stays yours.