[FEATURE] Agent that creates agents (Secure self-extensible "orchestrator" agent)

[felipevicens]

📋 Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct

📝 Feature Summary

Add support for an orchestrator agent capable of securely creating and managing specialized sub-agents via Kubernetes manifests (e.g., k8s_apply_manifest) and integrating them dynamically via A2A.

❓ Problem Statement / Motivation

Problem statement

Current limitation

Today, agents deployed through kagent are typically defined statically. While agents can orchestrate workflows, they cannot safely create and manage new agents at runtime as part of their reasoning process.

Additionally, updating an agent definition currently restarts the agent, which can interrupt ongoing execution and cause the orchestrator to lose its thread/context.

Who is affected

• Teams building complex multi-agent systems
• Developers implementing dynamic orchestration patterns
• Enterprise users who need scalable and modular agent workflows

Why is this needed

Many advanced agentic architectures (e.g. hierarchical planners or OpenClaw-like patterns) rely on a coordinator agent that can spawn specialized agents for subtasks.

Examples:

• An orchestrator decomposes a task into:
  • research agent
  • execution agent
  • verification agent

Each specialized agent can be created on demand, used for a specific task, and optionally cleaned up.

Currently, achieving this requires external orchestration or manual deployment, which breaks the agent autonomy model and complicates automation.

A native capability would allow kagent to support self-extending agent ecosystems while remaining Kubernetes-native.

💡 Proposed Solution

Proposed solution

Introduce support for an orchestrator agent capable of creating and managing new agents dynamically.

Key capabilities

1. Agent creation via Kubernetes MCP tools

Allow an orchestrator agent to call tools such as:
k8s_apply_manifest
search_agents_agentregistry (New tool)

to deploy new kagent Agent CRDs directly from the agent workflow.

Example flow:

Orchestrator agent 
↓
Search subagents in agentregistry
↓
Call search_agents_agentregistry
↓
Take the agent spec
↓
Call k8s_apply_manifest
↓
New kagent agent(s) deployed
↓
Call k8s_apply_manifest
↓
Orchestrator agent is updated with new sub-agents
↓
Orchestrator agent communicates via A2A

2. Dynamic A2A integration

Once created, the orchestrator should be able to:

• discover the new agent
• register it as an A2A endpoint
• delegate subtasks to it

3. Thread-safe orchestration

A constraint today is that updating the orchestrator agent causes a restart, which breaks active threads.

Possible improvements include:

• avoiding restarts for dynamic agent registration
• separating agent runtime state from configuration
• supporting hot-adding sub-agents without restarting the orchestrator

4. Security and guardrails

Since agents would be able to deploy other agents, safeguards are important.

Possible constraints:

• namespace-scoped deployment
• RBAC restrictions for MCP Kubernetes tools
• agent template allowlists
• manifest validation
• rate limits or quotas

The goal is to ensure this feature remains predictable and enterprise-grade, not an unrestricted self-replicating system.

🔄 Alternatives Considered

Alternatives to consider

1. External agent orchestrator

Use an external controller or pipeline to create agents dynamically.

Downside:

• breaks agent autonomy
• adds additional infrastructure

2. Dynamic agent creation

Write the agent prompt (+MCPs) and deploy it by using k8s_apply_manifest

Downside:

• security constrains
• unpredictable pattern

3. Job-style ephemeral agents

Instead of persistent agents, spawn short-lived execution agents (similar to Kubernetes Jobs).

This may simplify lifecycle management.

🎯 Affected Service(s)

Not Sure

📚 Additional Context

This feature is inspired by hierarchical agent systems where a coordinator dynamically spawns specialized workers.

Conceptual references:

• OpenClaw architecture
• hierarchical multi-agent task decomposition patterns

Example real-world use cases:

• autonomous research pipelines
• infrastructure automation agents
• dynamic evaluation pipelines
• multi-step LLM workflows

From a platform perspective, this would position kagent as a Kubernetes-native AI control plane, where agents can extend the system safely and dynamically.

Design goal

Enable agents to create and orchestrate other agents while preserving security, determinism, and operational predictability.

🙋 Are you willing to contribute?

• I am willing to submit a PR for this feature