Does the first agent in your directory become the boss?

Your product has four specialist agents. Their directory is sorted alphabetically because that was the easiest implementation. A request arrives, several agents consult the first entry, and that agent starts coordinating everyone else. Nothing in the product specification appointed a manager.

Is this useful self-organization, an accidental bottleneck, or simply the right specialist receiving the right work? A busy conversation graph cannot answer that question. You need to change the roster while preserving the task.

The immediate hook is YC’s October Agents in Games report, surfaced in today’s AI briefing. In its Minecraft civilization run, the authors report that 46 of the other 49 agents sent their first message to Ada, the first name in the directory. That observation invites a product experiment. It does not establish that directory position caused leadership, or that a particular model family will coordinate your business better.

For a small team building an agent product, today’s change is to include directory presentation in evaluation. Before adding another planner, rotate the existing roster and check whether necessary evidence still reaches the answer. This article proposes that experiment; we have not run the games, these model trials, or a customer deployment. The fictional task, budgets, schedule, and decision rules below are design choices to adapt, not measured results.

What the game observation establishes

The civilization run used 50 agents over three hours, with a directory, direct messages, and a shared sandbox. The report makes archived messages and activity material available. Its separate competitive games involve different settings and model–harness combinations. Those are useful observations of behavior under specific conditions, not interchangeable replications of a roster experiment.

The important missing counterfactual is straightforward: what would happen to the same task if another member appeared first, while startup timing, capabilities, and information stayed fixed? The report does not supply that controlled comparison. It is therefore premature to diagnose alphabetical leadership as a general model defect.

The released Minecraft harness supports teams, messaging, private sessions, and an optional shared machine. Availability makes inspection possible; it does not mean a default checkout reproduces the reported run. Likewise, the Mindustry release separates game configuration from model and harness configuration. Its README explicitly distinguishes environment validation from evidence about model performance. Preserve that distinction when designing your own test.

Our narrower inference is that a roster is a plausible behavioral input. A directory that looks like passive metadata deserves a controlled change before you rely on the interaction pattern it produces.

Separate position, responsibility, and permission

Three concepts easily get compressed into the word “leader.” Position is where a member appears in a list. Responsibility identifies who should coordinate this task. Permission determines which actions a process can actually execute. Moving a row should change only the first.

A model may infer responsibility from position without receiving additional permissions. Conversely, a designated coordinator can remain responsible even when listed last. If your product silently grants extra tools to the first row, you are testing a permission change, not presentation.

Older research gives reasons to investigate ordering without proving this particular mechanism. Lost in the Middle studies relevant-information position in long-context retrieval and question answering. Fantastically Ordered Prompts studies order sensitivity in few-shot examples. Neither paper tests agent directories or current game agents. They support treating ordering as a variable worth controlling; they cannot supply an expected effect size for your product.

Call the measured behavior routing concentration until you have evidence of authority. Receiving many messages might mean an agent is helpful, overloaded, repeatedly wrong, or merely relaying acknowledgments. None of those possibilities is resolved by giving the node a crown in a visualization.

Use a task with evidence that must move

Consider a fictional catalog assistant preparing a draft reply about an order. A customer asks whether two items can ship together at a quoted price. The product needs to combine current stock, shipping restrictions, and the active promotion. It cannot accept a fluent answer that consults only one specialist.

Create four agents with neutral identifiers. One owns the stock record, one the shipping rule, one the pricing record, and one a general catalog description. Each can read only its assigned synthetic source and send messages to every other member. All can submit a proposed answer to an external collector; the first valid submission ends the run. Submission rights are identical, and nothing can purchase, email, or change a real order.

Every member sees the same customer request and a directory explaining each role. Private source records contain the values; the directory contains capabilities rather than answers. The general catalog record is relevant context but cannot establish stock, shipping, or price. This creates a legitimate reason for evidence to move between agents.

Write the correct final fields and required source identifiers before running a model. Include a three-part answer, the applicable promotion version, and references to all three decisive records. A correct answer requires matching both the values and those source identifiers; invented identifiers or a copied outdated price fail. Have a second person check the fixtures if feasible. You are constructing an acceptance oracle, not asking the agents to vote on truth.

Change directory order without changing startup order

This is the most consequential control. The harness’s team documentation says agents start a few seconds apart, with a default stagger of three seconds. Merely rearranging a team configuration may therefore move both directory position and startup opportunity. A first mover could receive attention before other members are available.

For the proposed catalog simulator, initialize every session, verify readiness, and release the request through a shared start barrier. Render one identical ordered directory to every member. Change that rendered list through a separate parameter; keep process creation order, tool registration, private source assignment, and permissions unchanged. Record when each member becomes ready and receives the request.

If your framework derives all these things from a single array, separate them before running the experiment. Otherwise label the intervention honestly as a combined configuration-order change. It can still reveal fragility, but it cannot isolate directory presentation.

Also check that a search endpoint does not silently re-sort the directory. Save the exact returned bytes of both list and search results. A UI screenshot is insufficient if agents consume a different tool response. The test concerns the representation the model receives, including descriptions and any truncation.

Compare two routing policies across four rotations

Start with four cyclic rotations of one four-member directory. Every member occupies every position once. Use the same task instances under both policies:

The explicit policy tests a responsibility instruction, not a new enforced architecture. Any agent can still contact any peer and submit an answer. Record whether agents follow that instruction instead of assuming the label works. The shipping specialist’s position rotates with its row; the role itself stays fixed across the two policies.

For a first diagnostic batch, use three task variants and two fresh repetitions per cell: four rotations × two policies × three tasks × two repetitions equals 48 independent team runs. The variants should exercise a normal shipment, a restriction, and a promotion conflict. They are fixtures, not a representative market sample. Two repetitions are enough to encounter obvious instability, not enough to estimate a small effect precisely.

Randomize run execution order in advance and store the schedule. Pair comparisons by task variant, repetition block, and identity mapping. Use fresh sessions and clean storage for each run; shared memory from the previous rotation would turn later runs into a different treatment.

Keep labels and budgets from explaining the result

Neutral names do not eliminate identity effects. A model may associate a label, role description, or wording with authority. In the first batch, keep identifiers attached to their roles and rotate complete rows. That estimates sensitivity to those directory permutations for that particular mapping. It does not separately identify a pure position mechanism.

If the signal matters, run a second planned batch that reassigns neutral identifiers to roles using a balanced mapping. Preserve the private source ownership and role wording. Analyze the first and second batches separately before combining them. Do not add convenient permutations until a preferred result appears.

Give every team the same total model-token cap, maximum elapsed time, per-tool limits, and message-delivery behavior. Count all four agents’ tokens, failed tool calls, and inter-agent messages. If one policy spends more of the same cap, that is part of its behavior. An unrestricted policy must not receive a larger budget simply because its conversation is interesting.

Choose practical limits from your product’s cost and responsiveness requirements before the run. Set a separate maximum output size for each source so accidental document length does not become the treatment. Pin the model snapshot where supported, reasoning settings, harness revision, prompts, and source hashes. Provider nondeterminism still exists; a repeated seed is not a guarantee of identical execution.

Measure evidence delivery before message volume

The primary outcome is accepted completion per scheduled team run. Keep timeouts, model errors, incomplete answers, and abandoned runs in that denominator. If setup fails before the start barrier, mark the cell invalid, retain its record, and rerun under the predeclared setup policy. A provider outage after release is an outcome, not a convenient exclusion.

Evaluate every submitted candidate before applying the acceptance rule. Record two separate checks for each required fact: whether its authentic source identifier appears, and whether the claimed value matches the answer key. A candidate can cite every record and still state the wrong price. The collector accepts only a candidate passing both checks for all three facts. Coverage among accepted answers is therefore guaranteed by design; it is not an independent quality result.

For run-level diagnostics, use the accepted candidate on successful runs and the final submitted candidate on unsuccessful runs. Do not select an undefined “best” answer after seeing results. Keep no-submission runs as a distinct state, with absent coverage rather than a fabricated candidate. Report omission counts against all scheduled runs, showing no-submission separately, and additionally show coverage among runs that submitted a candidate. Candidate-level trajectories help diagnosis but are not independent experimental samples.

Capture time from request release to the first valid answer, with unsuccessful runs reported as unfinished at the cap rather than silently dropped from a latency average.

To inspect routing, record the recipient of each member’s first task-directed message. Exclude startup greetings using a rule written before scoring. Also retain total messages, first-row inbound share, and the number of unnecessary permission requests: requests for authorization that the fixture’s role and permission contract never requires. Human reviewers should resolve ambiguous cases from message text, blinded to rotation where practical.

A high first-row share with stable correctness may simply be an efficient hub. A high share accompanied by missing pricing evidence is more concerning. More messages are neither inherently good nor bad; their relationship to evidence completeness, latency, and cost is the product question.

Record a simple evidence path for each decisive fact: source owner, outgoing message, receiving member, and final answer field. This makes two superficially similar failures distinguishable. The pricing specialist might never receive a question, or it might send the correct discount that another agent later overwrites. The first suggests a discovery or routing problem; the second suggests synthesis or source-precedence trouble. Those are provisional diagnoses from inspectable events, not conclusions about a model’s intentions. Keeping the path lets the next intervention target the broken step.

Use a run sheet that exposes confounds

The following is a reusable record specification, not a report of completed trials. Null values mean unmeasured, not zero. Store detailed events in a separate file and reference it from each record.

experiment: catalog-directory-routing-v1
run_id: null
task_variant: null
repetition_block: null
identity_mapping: null
policy: null # unassigned | explicit_shipping_coordinator
directory_order: []
directory_response_sha256: null
source_bundle_sha256: null
model_and_harness_revision: null
ready_times: {}
request_release_time: null
request_delivery_times: {}
total_token_cap: null
elapsed_time_cap_seconds: null
accepted_completion: null
required_evidence: [stock, shipping, pricing]
candidate_checks_log: null # sequence, authentic IDs, value correctness
diagnostic_candidate: null # accepted | final_submitted | no_submission
diagnostic_source_coverage: null # per source: present | absent
diagnostic_value_correctness: null # per fact: correct | incorrect | absent
first_task_message_recipients: {}
first_row_inbound_share: null
unnecessary_permission_requests: null
total_tokens: null
time_to_valid_answer_seconds: null
stop_reason: null
event_log: null
reviewer_notes: null

Add actual source identifiers and expected values to a protected answer-key file, not the agent-visible record. Preserve both agent claims and validator results. If the collector accepts an invalid source citation, stop the batch and repair the verifier; continuing produces more precisely recorded bad measurements.

The MAST study distinguishes system design, inter-agent misalignment, and task verification failures. That taxonomy is useful for annotating your traces, but it does not diagnose their causes automatically. Mark a missing price as an observed failure first. “First-row authority caused it” is a hypothesis requiring the controlled comparison.

Read the paired results without inventing a winner

Prepare a table for every policy and rotation showing scheduled runs, accepted completions, diagnostic-candidate source omissions, incorrect values, no-submission runs, unfinished runs, total tokens, and routing concentration. Keep the all-scheduled and candidate-submitting denominators visible rather than combining no submission with a missing citation. Show task-level outcomes beside pooled counts. Six runs per cell in the diagnostic design are too few to hide behind a polished percentage.

Compare each task’s rotations within the same policy. Then ask whether explicit coordination reduces the spread across positions while preserving accepted completion. Because interactions inside a team are dependent, the team run is the analysis unit. Forty messages from one run do not create forty independent samples. With only three task variants, any broader claim about task populations remains weak even if model repetitions are numerous.

Keep three interpretations separate. A rotation-associated change is evidence of configuration sensitivity under these conditions. A repeated position-linked routing pattern across balanced identity mappings is stronger evidence of position sensitivity. A causal explanation involving attention, startup advantage, or inferred social authority requires further intervention; the message graph alone does not distinguish those mechanisms.

If results are noisy, publish the uncertainty internally and expand the predefined task set. Do not declare no effect from a small batch. If you need a quantified rollout claim, plan a larger study around the smallest harmful correctness or latency change, with appropriate uncertainty at the team-run level. This diagnostic batch is for finding and understanding failure, not certifying a universal absence of bias.

Choose a product response that matches the failure

Use the evidence to choose the next change rather than automatically building a manager. The decision table below proposes responses; it contains no benchmark-derived universal thresholds.

There is no requirement that every member receive equal traffic. Specialization legitimately creates unequal load. The product concern is whether an incidental list order makes necessary expertise unavailable, not whether a network diagram looks democratic.

Anthropic’s account of its research system describes the importance of clear delegation boundaries and the additional cost of multi-agent work. It is one production team’s account, not validation of this proposed intervention. The relevant lesson for our decision is to measure the complete system: an explicit coordinator that improves one trace but doubles work elsewhere may not be a useful change.

Know when this experiment is the wrong tool

This design fits products where agents see a directory and can choose whom to contact. It is less informative for a fixed pipeline whose edges are enforced in code, a single agent with deterministic tool routing, or a product in which the first member really is the authorized manager. Those systems have different questions. Do not remove legitimate authority just to make the fixture symmetrical.

The fictional catalog task also deliberately removes live users, changing inventory, and irreversible side effects. Passing it does not establish production safety, privacy, or commercial value. A follow-up needs representative tasks, realistic source freshness, external-state verification, and the product’s ordinary authorization controls. Evidence completeness cannot substitute for those controls.

LangChain’s October 29 Managed Deep Agents release adds background subagents and ongoing orchestration. That is a current example of why routing remains a product surface as delegated work becomes more interactive. It does not establish that LangChain has the directory behavior observed in YC’s games. Apply this experiment only where the actual agent-visible interface presents the relevant choice.

For the first implementation pass, inspect one real directory response, build the four-member synthetic fixture, and verify that list order is independent of launch order. That inspection may reveal a confound before any paid model call. Then run the scheduled batch and review every missing-evidence case before changing the architecture. The useful artifact is a comparison you can repeat after a roster edit. Your next specialist should earn its place by improving completed work, and your list sort should not silently decide how that work gets coordinated.

References

1. YC Labs, Agents in Games, October 2026
2. YC, Minecraft agent harness
3. YC, Running a team: directory, DMs, shared machine, and startup staggering
4. Olam Labs, Multi-Agent Mindustry README
5. Liu et al., Lost in the Middle: How Language Models Use Long Contexts
6. Lu et al., Fantastically Ordered Prompts and Where to Find Them
7. Cemri et al., Why Do Multi-Agent LLM Systems Fail?, revised version
8. Anthropic, How we built our multi-agent research system
9. LangChain, Managed Deep Agents v0.10: Browser use and asynchronous subagents