AI Agents Meta Orchestrator

AI Agents Meta Orchestrator

The single entry skill for building agents that build — the meta layer above any one agent app. It locates the task on the lifecycle × concern map (plan → compose → orchestrate → loop → audit → economize → evolve) and delegates to one of 14 specialist spokes. The cross-cutting decision every spoke turns on — eval-first execution with a default-deny autonomy boundary — lives in ai-agents-meta-core; read it before wiring an autonomous loop, granting tools, or routing by model cost.

Cluster map (intent → spoke)

Foundation & discipline

• agentic-engineering — the core practice: eval-first execution, decomposition, cost-aware model routing.
• search-first — research-before-coding; find existing tools/libs/patterns before writing custom agent code.

Plan & compose

• blueprint — turn a one-line objective into a multi-session construction plan; each step has a cold-start brief, dependency graph, and adversarial review gate.
• plan-orchestrate — read a plan, decompose into steps, and emit ready-to-paste per-step agent chains for an orchestrator command.

Architect the runtime

• agentic-os — build a persistent multi-agent OS on Claude Code: kernel, specialist agents, slash commands, file-based memory, scheduled automation, no external DB.
• dynamic-workflow-mode — design task-local harnesses, eval gates, and reusable skill extraction for adaptive agent runs.

Orchestrate & loop

• team-agent-orchestration — run squads with work items, ownership, agent Kanban, merge gates, and control-pane handoffs.
• continuous-agent-loop — patterns for continuous autonomous loops with quality gates, evals, and recovery controls.

Audit & debug

• agent-architecture-audit — full-stack 12-layer diagnostic; finds wrapper regression, memory pollution, tool-discipline failures, hidden repair loops.
• agent-introspection-debugging — structured self-debugging: capture → diagnose → contained recovery → introspection report.

Prompt & economics

• prompt-optimizer — analyze a draft prompt, match it to available components, emit a paste-ready optimized prompt (advisory only).
• cost-aware-llm-pipeline — model routing by task complexity, budget tracking, retry logic, prompt caching.
• token-budget-advisor — give the user an informed choice about response depth/token spend before answering.

Evolve

• continuous-learning-v2 — observe sessions via hooks, mint atomic instincts with confidence scoring, evolve them into skills/commands/agents (project-scoped).

Folded spokes

Additional planning/architecture specialists folded into this cluster. Route to them on demand the same way as the cluster-map spokes above.

Plan & compose (heavyweight planning)

• swarm-architect — upgraded large-scale planning protocol: interactive discovery, 80-task default granularity, phase→wave→swarm decomposition with explicit dependencies, verification gates, and dispatch-aware GitHub issue sync. Reach for it when blueprint is too lightweight and you need a production-grade, heavily parallelized execution plan.
• task-master-planner — interactive Taskmaster protocol producing 70–80+ schema-complete tasks (phases/waves/swarms) with verification gates and GitHub issue synchronization; ships JSON blueprints plus context-collection and plan-generation scripts. Use to turn a spec/architecture doc into a GitHub-synced, orchestrator-ready task plan.

Architect the runtime (spec generation)

• arch-orchestrator — turn a raw product brief into a consistent, implementation-ready spec pack under specs/ (frontend, backend, API, AI) by coordinating specialist agents and enforcing a project's preferred stack as hard constraints. Use when the ask is "create architecture / generate specs / turn my brief into docs".

Routing notes:

• "I have a brief, give me the docs/specs" → arch-orchestrator.
• "I have specs, give me a big parallelized build plan" → swarm-architect (or task-master-planner when you specifically want the Taskmaster JSON + GitHub-issue sync flow); for lighter single-PR planning stay on blueprint/plan-orchestrate.

Routing rules by intent

1. "Help me plan / scope a big agent project" → blueprint; if a plan already exists and needs an execution chain → plan-orchestrate.
2. "Should I build this myself?" → search-first first, always, before any custom-code spoke.
3. "Stand up the agent system / kernel / memory" → agentic-os; for a one-off adaptive run instead of a standing OS → dynamic-workflow-mode.
4. "Coordinate several agents" → team-agent-orchestration; if it should run unattended with gates → continuous-agent-loop.
5. "It's misbehaving / regressed / loops forever" → agent-architecture-audit to localize the layer, then agent-introspection-debugging to recover.
6. "It's too expensive / too slow / too verbose" → cost-aware-llm-pipeline (API spend), token-budget-advisor (per-answer depth), prompt-optimizer (wasteful prompts).
7. "Make it learn from itself" → continuous-learning-v2.
8. "Build/run the eval harness or benchmark the agent itself" → that tooling lives in the quality-eval cluster (agent-eval, eval-harness, verification-loop, benchmark, production-audit); this cluster owns eval-first discipline, not the harness.
9. Unsure / cross-cutting → pull the model from ai-agents-meta-core, then route.

Standard flow

1. Locate the task: which lifecycle stage (plan → compose → architect → orchestrate → audit → economize → evolve) and which concern.
2. If it touches autonomy, tool grants, eval gates, or model/cost routing, pull the model from ai-agents-meta-core first — these are interlocking, not independent.
3. Delegate to the spoke(s). Multi-step asks fan out in lifecycle order (e.g. "build and ship a multi-agent feature" → search-first → blueprint → plan-orchestrate → team-agent-orchestration → agent-architecture-audit).
4. Return: chosen spoke(s), the autonomy/eval/cost changes implied, and the next action.

Guardrails

See ai-agents-meta-core. In short: eval-first — no autonomous step ships without a gate that can fail it; default-deny autonomy — grant the narrowest tool/permission/loop budget that works and state every widening; research before building (search-first) so you don't hand-roll what already exists; route by task complexity, not habit to control cost; and keep a human decision point at every handoff. The value of this cluster is a governable agent system — don't let a loop run unbounded or a prompt balloon silently.

Loading spokes on demand

To keep CLI startup context lean, this cluster's spokes are not separately registered as skills — only this orchestrator and its *-core are enumerated. When you route to a spoke named above, load it on demand by reading its file:

~/.agents/skill-clusters/skills/<spoke-name>/SKILL.md (or skills/<spoke-name>/SKILL.md inside the skill-clusters repo).