Staging: spawn_parallel_agents registered under both 'tool' and 'graph' kinds — ambiguous dispatch

[Al629176]

Summary

spawn_parallel_agents is registered under two kinds simultaneously — both tool and graph — in the tinyagents registry. This is flagged as a non-fatal diagnostic but callers cannot reliably disambiguate which kind is invoked, which can cause incorrect dispatch at runtime.

Log evidence (staging, 2026-08-19)

02:08:43 WRN [tinyagents][registry] non-fatal diagnostic: name `spawn_parallel_agents` is registered
under multiple kinds (tool, graph); ensure callers disambiguate by kind
kind="tool" name=spawn_parallel_agents

[Repeats on each agent turn]

Impact

Non-fatal but creates ambiguous dispatch. If a caller resolves spawn_parallel_agents by name without specifying kind, it may get either the tool or graph variant non-deterministically. Could manifest as inconsistent parallel agent spawning behaviour that's hard to reproduce.

Fix direction

Determine whether spawn_parallel_agents should be a tool or a graph and remove the duplicate registration. If both are intentional, enforce explicit kind disambiguation at all call sites.

[M3gA-Mind]

How to fix this

Root cause: all_graph_topologies() labels the spawn-parallel graph report "spawn_parallel_agents" — the same string SpawnParallelAgentsTool::name() returns. Those labels are not cosmetic: the per-turn assembler re-uses each report's name verbatim as the registration key for a ComponentKind::Graph descriptor, so one name lands under two kinds and CapabilityRegistry::diagnostics() flags it on every turn. Renaming the label is the whole fix.

Where (main @ e1c332bf0):

• src/openhuman/agent/tinyagents/topology.rs:69 — out.push(describe("spawn_parallel_agents", &t)); — the only site that changes.
• src/openhuman/agent/tinyagents/mod.rs:1973 — capability_registry.register_descriptor(ComponentKind::Graph, report.name) — why the label above is a registration key, not a display string.
• src/openhuman/agent/orchestration/tools/spawn_parallel_agents.rs:41 — the tool name it collides with. This one does not change: the tool name is in agent prompts, agent.toml archetypes and docs/, and renaming it would be a user-visible break.
• Detection, for reference: vendor/tinyagents/src/registry/capability/mod.rs:499-508 → vendor/tinyagents/src/registry/diagnostics.rs:142; logged at src/openhuman/agent/tinyagents/mod.rs:612.

The change: one string literal at topology.rs:69, "spawn_parallel_agents" → a distinct label. Nothing else. I checked every consumer of all_graph_topologies() — there are exactly three (mod.rs:1973, and agent/schemas.rs:442 / :591 for the agent.graph_topologies debug RPC and the registry snapshot) — and all three treat name as an opaque label. Nothing dispatches on it, and app/src and docs/ reference spawn_parallel_agents only as the tool, so no frontend or doc breaks.

This already exists as PR #5617, and I would merge that rather than write it again. I re-checked it against current main today: mergeable: MERGEABLE (not conflicted, despite three commits touching topology.rs since it was opened), both hunk anchors still present, and the signatures its new test depends on — tools::all_tools (8 args, unchanged), AuditLogger::new(AuditConfig, PathBuf), AuditConfig's three fields — are all unchanged, so it should still compile. Its CI was green and both bot reviews ended approving; mergeStateStatus is BLOCKED only on the required human approvals. Its regression test is genuinely non-vacuous: it builds the real all_tools set, asserts spawn_parallel_agents is in it, then asserts no graph label collides — revert the one-line rename and that assertion fires. Naming nit if it is touched again: the sibling labels are namespaced (agent_teams:member, workflow_runs:scheduler, agent:researcher), so spawn_parallel:graph would read more consistently than spawn_parallel_graph — not worth another CI round on its own.

How to prove it: the test in #5617 is the right one and already fails on revert. If it is rewritten, the shape that matters is: collect all_graph_topologies(), collect all_tools(...) names, assert the intersection is empty — that guards every future graph label, not just this one.

Risk / blast radius: small and contained. The label crosses the wire in the agent.graph_topologies debug RPC and in agent.registry_snapshot; anything pinning the old string in a snapshot fixture would need updating (I found none). Worth knowing: the block at mod.rs:603-625 is a fail-closed gate — Error-severity diagnostics abort the turn before the first model dispatch, and only Warning severity is logged. name_reused_across_kinds is currently Warning, which is why this is noise and not an outage. That is an argument for fixing the collision rather than muting the log: if that check is ever promoted to Error as a hardening, this exact name aborts every turn.

Not covered by this: the issue's stated impact — that a caller "may get either the tool or graph variant non-deterministically" — is not reachable, and no fix is needed for it. Every CapabilityRegistry accessor is kind-scoped (tool(name), graph_blueprint(name), has(kind, name), metadata(kind, name), resolve_name(kind, name)); there is no name-only cross-kind lookup. And the graph is registered by register_descriptor — a name with no blueprint attached — so graph_blueprint("spawn_parallel_agents") returns None and there is nothing executable to mis-dispatch to. spawn_parallel_agents the tool works correctly today. The one real (latent) consequence is narrower: CapabilityResolver::from_registry seeds its subgraphs allowlist from ComponentKind::Graph names (vendor/tinyagents/src/language/capability_resolver.rs:168), so a .rag program with a subgraph node referencing spawn_parallel_agents would pass name validation and then find no blueprint to bind. The rename closes that too. So the defect is real, but it is registry hygiene and log noise — worth reflecting in the priority.

APP CHECK — I could not re-confirm live reproduction, and did not want to claim it. On 2026-08-21 this fired 8 times in one session. The app running now from this checkout (booted 14:18) has had no agent turn at all — zero tool spec filter and zero [registry] lines in its log — so the diagnostic is absent for want of a trigger, not because it stopped. The code path is provably intact, so it should fire on the first turn. To confirm: send the agent any one chat message, then grep the app log for is registered under multiple kinds. Expected — one WRN ... [registry] non-fatal diagnostic: name \spawn_parallel_agents` is registered under multiple kinds (tool, graph)per turn, andspawn_parallel_agentspresent in thetool spec filter` visible-names list on the same turn (the tool still works). If the warning does not appear after a real turn, something else changed and this needs re-opening from scratch.

Confidence: high on the mechanism and on the fix — the label → registration → diagnostic chain was traced end to end in source on this commit, and the claimed impact was disproved by enumerating the full registry API. Medium only on current live reproduction, for the reason above.

— fleet research, verified against main @ e1c332b