A research agent often reads a brief, runs one search after another, drafts, checks, and returns the result. The workflow looks orderly, but independent searches still wait in line.
If six searches do not depend on one another, they can run together. The delay comes from the graph, not necessarily the model or the search tool.
In a thread on agent topologies, systems engineer Hanako (@hanakoxbt) describes this as a graph problem: the dependencies do not match the work.
I have not implemented or benchmarked a 100-agent system here. The eight checks below are a design review distilled from that thread, with my own cautions added; they are not performance results.
2. Context Engineering: Controls what the model sees.
3. Harness Engineering: Builds the machinery around the model call.
4. Loop Engineering: Iterates a single unit of work through feedback.
5. Graph Engineering: Coordinates the entire multi-agent job.
Eight checks distilled from the thread
Step 1 — Test every dependency
Agent workflows are often written as straight lines because instructions arrive that way: "Do this, then that, then the other thing." Written order does not prove a dependency.
Hanako’s dependency test is whether the second step reads what the first step produced. If it does not, serializing the nodes adds waiting without carrying data forward.
For each arrow, check whether the next node consumes the previous node’s output. Remove the edge when written order is the only reason it exists.
Step 2 — Give nodes contracts
Parallel work still has to rejoin. When a node returns unformatted prose, downstream nodes spend tokens interpreting it. Hanako’s useful contract has four parts:
- One job: Keep the responsibility narrow enough to name plainly.
- Explicit input: State what the node consumes.
- Structured output: Use typed JSON or a schema when later branches depend on fields.
- Named failure state: Return data such as
not_foundinstead of leaving every failure as an uncaught exception.
Step 3 — Start with four common shapes
Step 4 — Add joins only where needed
A fan becomes another chain if every branch waits at an unnecessary barrier. Join only when the next stage needs the full set, as with cross-source deduplication, global ranking, or coverage checks. Otherwise, let results continue as they arrive.
Step 5 — Separate classification from authority
A model can classify a request without deciding what it is allowed to execute:
- Model: Return a category or risk score.
- Route table: Map that result to permitted tools and execution paths.
Step 6 — Put verification on its own boundary
In Hanako’s framing, a verifier does not add content; it decides whether work may move downstream. I would keep that permission separate from the producing node.
Separate production, verification, and publication permissions. A second model call is not automatically independent evidence, so the verifier also needs explicit checks and a failure path.
Step 7 — Make state durable
A runnable graph must track completed work, artifacts, and remaining retries:
- Pass references, not transcripts: Store reports and return an ID so downstream nodes can read the exact artifact.
- Make operations idempotent: A retry should not duplicate a side effect or corrupt a record.
Step 8 — Price the graph
Parallel breadth costs tokens and tool calls. Measure total input/output tokens, external requests, wall time, and failure rate against a single-agent baseline on the same task set.
Model assignment should follow measured task requirements rather than a fixed list of model names. A cheaper model may suit bounded extraction; synthesis or verification may need a stronger one. Re-test those choices when models, prompts, or tool interfaces change.
When a graph is the wrong tool
Keep a single agent in a simple loop when:
- The task is short and bounded.
- A single context window holds all relevant context.
- No work can run independently.
- A human reviewer can check the final output quickly.