/skill-agent-topology

name: skill-agent-topology
description: "Audit whether a multi-agent setup earns its coordination cost — use before adding an agent, or when a workflow feels slow or agents agree without adding signal"
disable-model-invocation: true

> **Host: Codex CLI** — This skill was designed for Claude Code and adapted for Codex. > Cross-reference commands use installed skill names in Codex rather than `/octo:*` slash commands. > Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. > For host tool equivalents, see `skills/blocks/codex-host-adapter.md`.

Agent Topology Audit

Most advice about multi-agent systems is about how to add agents. This is about whether to. It audits a setup you already have, counts what each boundary between agents costs, and compares that against what the boundary buys. Removing an agent is a valid, and often the correct, result.

The framing comes from Liu, Canhui (2026), *The Organizational Behavior of Agentic AI* ([arXiv:2606.30986](https://arxiv.org/abs/2606.30986)), which models coordination overhead as **contextual transaction cost** — the cost of making task context usable across an agent boundary.

When To Use

• Before adding another agent, seat, or phase to a workflow that already works.
• When a workflow is slow and it is not obvious which part is earning its time.
• When agents keep agreeing. Agreement that costs three dispatches and produces

what one would have produced is overhead wearing the costume of consensus.

• When a handoff keeps losing something and the fix keeps being "add more

context to the prompt".

• After a workflow produced a bad result and you want to know whether the

topology or the models were at fault.

When Not To Use

• To pick a workflow for a new task. That is `/octo:auto`, which already routes

by intent, or `skill-decision-support` for a general option comparison.

• To decide whether to delegate a task to agents at all. That is the allocation

step in `skill-intent-contract`.

• To choose between providers or models. See `skills/blocks/frontier-model-routing.md`.
• For a single-agent task. There are no boundaries to count.

Inputs

• The workflow or setup under audit: which agents or seats, in what order, with

what passing between them.

• What each agent receives and what it returns. Prompt and output shape matter

more than model identity here.

• Optionally, a transcript or run directory, which turns estimates into

observations.

If the setup is only described rather than run, say so in the output. An audit of a described topology is a prediction; an audit of a transcript is a measurement.

Workflow

1. Draw the boundaries

List every point where context crosses from one agent to another. Include the entry boundary (human to first agent) and the exit boundary (last agent to human) — they cost too, and the exit boundary is where synthesis quality is usually won or lost.

Count them. The number of boundaries, not the number of agents, is what drives coordination cost. Three agents in a star cost fewer crossings than three in a chain.

2. Name what is lost at each boundary

For each crossing, work through these and record only the ones that actually apply. Naming a cost that is not present is as unhelpful as missing one:

• **Token and latency burden** — what it costs to restate context.
• **Handoff** — what the receiving agent needs that the sending agent held but

did not pass.

• **Compression loss** — what got summarised away. Free-text summary between

agents is the usual culprit.

• **Semantic drift** — where the receiver's reading of a term differs from the

sender's.

• **Verification burden** — work spent checking the other agent rather than

doing the task.

• **Governance** — approvals, gates, and waiting.

3. Name what the boundary buys

A boundary is earned only by a gain that a single agent could not produce:

• **Specialisation** — genuinely different capability, not a different label on

the same model.

• **Parallelism** — real wall-clock reduction on independent work.
• **Cross-vendor diversity** — different training data and different blind

spots. Note that same-family agreement is not this; see `skills/blocks/frontier-model-routing.md`.

• **Adversarial review** — a seat whose job is to disagree, where disagreement

is the product.

4. Compare against the single-expert null

The baseline is always one capable agent doing the whole task. The cited research found human-imitation topologies — pipelines, manager hierarchies, and committees deliberating in free text — measuring *below* that baseline, while agent-native forms built around shared memory measured above it. The single expert stays competitive precisely because it pays no internal transaction cost.

So the **burden of proof falls on the boundary**. Absent a gain term that a single agent could not deliver, the recommendation is to collapse.

Treat this as a directional prior, not proof. It is one simulation study plus model traces, and it is the source of the framing rather than a measurement of your setup. Effect sizes from that paper are deliberately not reproduced here: they describe the study's conditions, not yours.

**One caveat that changes the reading, and must not be skipped.** What the study penalised was committee deliberation in free text with no independent evidence — agents talking to each other about the same information. Providers that bring genuinely independent evidence, different models with different training data and real web search, are not that committee. `/octo:debate` and `/octo:council` are therefore better positioned than the studied form. The problem those results identify is the handoff, not the panel.

5. Reuse the overlap gate that already exists

Do not invent a new "is this agent adding anything" metric. The council roster already has one: `council_persona_overlap_score` in `scr