fix(subagent): dispatch subagents through per-agent provider; enforce allowlist on self-spawn; attribute responses

[securityguy]

Problems

1. Subagent always used the global provider

SubagentManager was initialised with the single global LLMProvider passed into NewAgentLoop, plus the calling agent's model name string (e.g. "openrouter-gpt-5.4"). When the global provider happened to be claude-cli, every spawn attempt failed because claude was invoked with --model openrouter-gpt-5.4 — a picoclaw model alias it does not recognise.

2. Named agent delegation was unimplemented scaffolding

The spawn tool accepts an agent_id parameter described as "Optional target agent ID to delegate the task to", and SubagentTask stores the value — but runTask always used sm.provider and sm.defaultModel regardless. Spawning agent_id="karen" ran with Amber's provider, not Karen's.

3. Allowlist did not cover self-spawns

The allowlist check in SpawnTool only ran when agent_id != "". An empty agent_id bypassed the check entirely, so allow_agents: ["karen"] could not prevent an agent from spawning itself.

4. Subagent responses had no attribution

When a named subagent completed a task its raw output was published directly to the user with no indication of which agent produced it.

Changes

pkg/tools/subagent.go

• NewSubagentManager now takes a SubagentManagerConfig struct that accepts a ProviderDispatcher, FallbackChain, the calling agent's own SelfCandidates, its CallerAgentID, and a CandidateResolver callback for looking up other agents' candidates.
• Added resolveLoopConfig(agentID): uses selfCandidates for self-spawns and resolves the target agent's candidates via CandidateResolver for named spawns, so each subagent runs with its own configured provider and model.
• Added attributedContent(agentID, content): prefixes the user-visible result with the agent's name in bold when a named agent produced it. Self-spawns are unaffected.

pkg/tools/toolloop.go

• ToolLoopConfig gains Dispatcher, Candidates, and Fallback fields. When set, RunToolLoop dispatches per-candidate through the ProviderDispatcher with full fallback chain support, mirroring the main agent loop. Falls back to the existing Provider/Model pair when not configured.

pkg/tools/spawn.go

• Self-spawns (empty agent_id) now resolve to the caller's own ID before the allowlist check, so allow_agents: ["karen"] correctly rejects an unqualified spawn in addition to blocking explicit agent_id="amber" calls.

pkg/agent/loop.go

• registerSharedTools accepts dispatcher and fallbackChain and constructs each agent's SubagentManager with its own candidates, caller ID, and a registry-backed candidate resolver closure.
• The fallback chain is built before registerSharedTools is called so it can be shared with both the main loop and the subagent managers.
• ReloadProviderAndConfig builds a fresh fallback chain for the reloaded registry.

[yinwm]

Thanks for the work — the core subagent dispatch design (ProviderDispatcher, candidateResolver, self-spawn allowlist fix, attribution) is well thought out.

However, I'm requesting changes for three reasons:

1. PR bundles 10+ unrelated features

This single PR includes gemini-cli provider, multi-Telegram bots, strict_compat, tool call extraction improvements, claude-cli stdin system prompt, launcher gateway detection, README rewrite, dependabot removal, and the ProviderDispatcher — all mixed together. Each should be a separate PR against main so they can be reviewed, tested, and landed independently.

2. Outdated base with guaranteed conflicts

This branch is based on ~March 12 main. PRs #2038 (LightProvider) and #2068 (config/security refactor) have since been merged, causing conflicts in loop.go, instance.go, and loop_test.go. A rebase onto latest main is needed.

3. Architectural overlap with #2098

#2098 takes a simpler approach (direct per-agent provider creation in NewAgentInstance) while this PR introduces ProviderDispatcher as a caching middleware layer. The project needs a single consistent direction — maintainer should decide before both land.

Suggested path forward:

• Extract subagent dispatch + ProviderDispatcher as a standalone PR (rebased on latest main)
• Submit gemini-cli, multi-Telegram, strict_compat, etc. as separate PRs
• Coordinate with #2098 author on unified provider resolution approach

Happy to review each PR individually.

[securityguy]

Thank you for the feedback. Each fix was developed on its own branch and submitted as a separate PR, however since I needed the software to be functional, I merged each change into my local main as I went. I apologize — I didn't anticipate that this would cause the subsequent PR branches to carry the accumulated history, effectively combining changes from multiple PRs.

Given the number of changes to your main branch and the volume of outstanding PRs, I'm not in a position to rebase and resubmit at this time. I hope the individual branches and their commit messages are still useful as a reference please feel free to use any of the code you find helpful, and to close any PRs that are no longer relevant.

[securityguy]

FYI, I've left all the branches here in case you find them helpful:

https://github.com/securityguy/picoclaw/branches/yours