§1The card, and the trap inside it
A system-design card did the rounds this week. You have an AI product with four specialised agents: a Planner that breaks down the task, a Researcher that pulls context, a Coder that implements, and a Reviewer that catches bugs. Work flows left to right, there is a state store hanging off the side, and there are per-step timeouts. Then it asks you to pick one of four orchestration patterns: A a centralised orchestrator, B choreography over an event bus, C a DAG that parallelises independent steps, or D a supervisor that watches the others and decides whether to retry, reroute or escalate to a human.
It is a good card. It is also a trick, and not the kind it thinks it is. The trick most people fall for is treating it as a multiple-choice question with one right answer. It is not. Three of those options answer one question and the fourth answers a different question entirely. Pick "the best one" and you have already misread what is being asked.
§2Topology is the first question, and it is the easy one
A, B and C are all answers to "how does work move between the agents". That is topology. A centralised orchestrator calls each agent in sequence and owns the control flow. Choreography lets each agent publish an event and the next one reacts, with no conductor. A DAG models the real dependency graph and runs independent branches in parallel. These are genuinely different shapes, and for this specific pipeline most of them are wrong.
The pipeline is nearly linear. Planner feeds Researcher feeds Coder feeds Reviewer. There is one honest opportunity to parallelise, which is the Researcher fanning out to several sources at once, and that is the only reason a DAG (C) is the truthful topology rather than a plain sequence. Choreography (B) is the one to avoid. Four agents wired through an event bus with no central trace is a debugging tax you pay every single day, in exchange for a decoupling you do not need at this size. Pub/sub earns its keep when you have dozens of services and teams that must not block on each other, not when you have four steps in a row. And a centralised orchestrator (A) is, for almost everyone, the correct place to start: one file to read, one place the control flow lives, one trace to follow when it breaks.
So if the card forced me to pick a topology, I would say a small DAG, and I would tell you that A is where you should actually begin and only reach for C when the Researcher fan-out starts to hurt. But the card is not really asking about topology.
§3Control is the second question, and it is the one that matters
Look at what the diagram bothered to draw. Per-step timeouts. A state store. An arrow that ends at "escalate to a human". None of those are about how work flows on the happy path. Every one of them is about what happens when a step fails. The Coder hangs. The Researcher returns rubbish. The Reviewer flags a bug the Coder cannot fix in one pass. That is the actual subject of the card, and only option D speaks to it.
D is the supervisor: a component whose job is not to move work forward but to notice when work has gone wrong and decide what to do about it. Retry this step. Reroute to a different path. Stop and ask a person. Here is the thing the card hides by listing D alongside A, B and C as if they compete: a supervisor is not a fourth topology. It is a layer that sits on top of whichever topology you chose. You can run a centralised orchestrator with a supervisor. You can run a DAG with a supervisor. The supervisor and the topology are orthogonal, which is exactly why presenting them as four mutually exclusive options is a category error.
So the exam answer is D, because failure handling is the real content of the question and D is the only option that addresses it. The engineering answer is that you do not pick D instead of A or C. You pick a topology and then you put a supervisor over it.
§4What composing it actually looks like
The honest design is A's simplicity with D's escalation. Start with a central orchestrator so there is one legible control flow, give the Researcher a parallel branch when it needs one, and wrap the whole thing in a supervisor that owns retries, timeouts and the handoff to a human. That is not a clever answer. It is the boring answer, and it is the one that survives contact with production.
It is roughly what we already run across our own agent fleet, and we did not arrive at it by picking a quadrant. The orchestrator and the supervisor are the same actor in our case, an agent that dispatches work and watches it. The state store is a plain todo and ledger table that every step reads and writes, so the work survives a crash mid-run. The "escalate to a human" arrow is a real approval gate that blocks the run until someone replies. And the reroute is replanning: when a step fails, the supervisor does not just retry the same plan, it rebuilds it. We never chose A or B or C or D. We assembled the parts the job needed. The quadrants are a teaching fiction, useful for a card and misleading for a build.
§5What the card is good for, and the one thing to take
I do not want to be unfair to it. The card is a sharp way to find out whether someone has confused "drew the boxes" with "designed the system". Anyone who answers A through D with a single letter and a confident face has told you they think topology is the whole job. Anyone who says "those are two different questions, here is the topology and here is the failure layer" has told you they have run one of these things at three in the morning.
The stealable step is small. When you next sketch a multi-agent pipeline, draw the happy path and the failure path in two different colours, and do not let yourself pick an orchestration pattern until both are on the page. The happy path picks your topology. The failure path picks your supervisor. They are not the same line, and the card that pretends they are is the card you should be ready to argue with. What does your failure path actually look like, and is anything in your current design even watching it?