Skip to content

feat: transform AI into Manager Agent with sub-agent delegation (Phase 7)#10

Open
coder-contrib-bot wants to merge 7 commits into
mainfrom
claude-code/manager-agent-delegation/8f3k2m9x
Open

feat: transform AI into Manager Agent with sub-agent delegation (Phase 7)#10
coder-contrib-bot wants to merge 7 commits into
mainfrom
claude-code/manager-agent-delegation/8f3k2m9x

Conversation

@coder-contrib-bot
Copy link
Copy Markdown
Collaborator

@coder-contrib-bot coder-contrib-bot commented May 27, 2026

Summary

Restructures the AI system into a clean 3-layer architecture that separates planning from execution:

User
 ↓
Manager (Planner / Router — LLM)
 ↓
ToolExecutor (Execution Layer — NO LLM)
 ↓
Tools / Services (action_tools, sales_tools, stock_tools, etc.)

Key principle: The AI only SELECTS tools. The backend EXECUTES.

  • Claude never writes SQL or touches the database
  • Claude only decides which tool to call and with what parameters
  • A pure Python execution layer runs the actual operations

New files

File Role
backend/app/ai/executor.py Execution layer — pure Python, no LLM. Maps tool names to service functions and runs them.
backend/app/ai/tools/tool_schemas.py Tool definitions (JSON schemas for Claude). Separated from execution logic.

Rewritten files

File Change
backend/app/ai/agents/manager_agent.py Now a planner only — uses Claude to decide tool calls, passes them to ToolExecutor
backend/app/ai/claude_client.py Thin entry point that delegates to ManagerAgent
backend/app/ai/prompts/system_prompts.py Simplified prompts reflecting the planner role

Deleted files

File Reason
sub_agents.py Eliminated nested LLM calls — no more sub-agents running their own Claude loops
sales_agent.py Old keyword-routing stub
inventory_agent.py Old keyword-routing stub
accounting_agent.py Old keyword-routing stub

How it works now

  1. User says "sell 5 meters of Royal Ceramica to Ahmed"
  2. Manager (LLM) plans: call search_customers("Ahmed")
  3. ToolExecutor (no LLM) runs the search, returns {id: 5, name: "Ahmed"}
  4. Manager (LLM) plans next: call search_products("Royal Ceramica")
  5. ToolExecutor (no LLM) runs search, returns {id: 12, price: 150}
  6. Manager (LLM) plans: call create_invoice(customer_id=5, items=[...])
  7. ToolExecutor (no LLM) runs it: validates stock → creates invoice → deducts inventory → records payment
  8. Manager (LLM) formats result for user: "Done! Invoice #42 created..."

The LLM is only in the planning loop. Execution is deterministic Python code.


GIT_AUTHOR_NAME: Claude (AI Agent)
GIT_AUTHOR_EMAIL: noreply@anthropic.com

This PR was generated by Claude Code (AI Agent).

Rewrites manager_agent.py as a true orchestrator that delegates to
specialized sub-agents via meta-tools. Updates claude_client.py to use
the delegation pattern instead of running all 25 tools monolithically.

The Manager Agent now has:
- 3 delegation meta-tools (sales, inventory, accounting)
- A few quick-lookup tools for simple queries
- Claude decides routing via reasoning, not keyword matching

Each sub-agent runs its own independent tool loop, executes multi-step
operations autonomously, and returns a final result to the Manager.

GIT_AUTHOR_NAME: Claude (AI Agent)
GIT_AUTHOR_EMAIL: noreply@anthropic.com
Rewrites all agent prompts to reflect the new delegation model:
- Manager knows it delegates, not executes directly
- Sub-agents know they are specialized executors called by the Manager
- Includes clear routing examples and multi-domain handling

GIT_AUTHOR_NAME: Claude (AI Agent)
GIT_AUTHOR_EMAIL: noreply@anthropic.com
The old SalesAgent, InventoryAgent, and AccountingAgent were keyword-based
routing stubs with no execution loop. They are fully superseded by
sub_agents.py which implements proper Claude tool loops.

GIT_AUTHOR_NAME: Claude (AI Agent)
GIT_AUTHOR_EMAIL: noreply@anthropic.com
GIT_AUTHOR_NAME: Claude (AI Agent)
GIT_AUTHOR_EMAIL: noreply@anthropic.com
GIT_AUTHOR_NAME: Claude (AI Agent)
GIT_AUTHOR_EMAIL: noreply@anthropic.com
Architecture is now:
  User → Manager (Planner/Router, LLM) → ToolExecutor (no LLM) → Tools/Services

Changes:
- NEW executor.py: pure Python execution layer, maps tool names to service
  functions, no LLM involved
- NEW tool_schemas.py: tool definitions separated from execution logic
- REWRITE manager_agent.py: planner only, delegates execution to ToolExecutor
- SIMPLIFY claude_client.py: thin entry point
- UPDATE system_prompts.py: Manager knows it plans, doesn't execute

The LLM (Claude) only decides WHICH tools to call. The execution layer
runs them without any AI involvement.

GIT_AUTHOR_NAME: Claude (AI Agent)
GIT_AUTHOR_EMAIL: noreply@anthropic.com
The sub-agent pattern (each domain agent running its own Claude tool loop)
is replaced by the simpler architecture: Manager plans, ToolExecutor runs.
No LLM in the execution path.

GIT_AUTHOR_NAME: Claude (AI Agent)
GIT_AUTHOR_EMAIL: noreply@anthropic.com
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant