[agent][efficiency] Orchestrator over-delegates trivial local queries + pure-reasoning to sub-agents (should be direct/single-turn)

[M3gA-Mind]

Orchestrator over-delegates trivial local queries + pure-reasoning tasks to sub-agents (should be a direct tool call / single main-agent turn)

Found via a scripted agent-efficiency eval on staging (chat-v1 orchestrator — this is a routing DECISION, not confounded by tier latency).

Evidence

• "List my recent conversation threads" → spawned 2 "Memory Agent" sub-agents that called memory_tree×4, memory_doctor, memory_recall — never threads_list. (should be one threads_list call)
• "Who is Priya Nair to me" → spawned a "Memory Agent" (memory_recall, memory_tree×2, memory_doctor).
• "Add 'Sam' as an alias for Samuel Ortiz" → spawned a "Profile Memory Agent" (people_list). (should be one manage_profile_memory call)
• "Break down 'launch a weekly newsletter' into an ordered plan" (pure reasoning, no external data) → spawned 2 serial sub-agents and never finished.

Contrast: "Show my goals" correctly called goal_get directly and finished in ~7s; the delegated ones ran 120-480s (and several returned empty — see the separate graceful-degradation issue).

Ask

Tighten the orchestrator's delegation/routing heuristic so single-tool local operations (thread list, people/profile lookups, alias add) and pure local reasoning (planning/breakdown with no external data) are handled in the main turn, not fanned out to a sub-agent. Investigate the delegation decision path in the agent harness/orchestrator. Also: the delegated "Memory Agent" used memory tools for a threads query (memory_tree/memory_doctor instead of threads_list) — a wrong-tool-routing symptom worth fixing.

VERIFY the delegation decision in code before changing; if eager delegation here is intentional design, report back rather than forcing a change.